序上一篇我们介绍了 k8s 的基本架构,我们在这篇文章将介绍 Kubernetes 关键组件和概念。还是先来一张图:根据上图我们分别对Deployment、ReplicaSet、Pod详细的介绍,其他的几个在上一篇也做了介绍:DeploymentDeployment 是 Kubernetes 中的资源对象,为应用程序提供声明性更新。部署允许你描述应用程序的生命周期。也就是说他的主要作用就是管理和控制 Pod 和 ReplicaSet,监控它们运行在用户所期望的状态中。例如应用程序使用哪些镜像像、应该有的 Pod 数量以及更新它们的方式。ReplicaSetReplicaSet 是一个运行 Pod 的多个实例并保持指定的 Pod数量不变的进程。目的就是在任何时间内维持集群中运行的指定数量的 Pod 实例,以防止用户在 Pod 发生故障或无法访问时失去对其应用程序的访问权限,如果监控到某一个Pod不能继续服务的时候,他会确保我们的应用程序Pod总体服务数量保持在我们期望的数量,然后再重新启动一个Pod。这里说一下Replication Controller 与 ReplicaSet,Rep
Kubernetes 概述当下,我们很多项目于都在Cloud Native(云原生)的上面,这种方法旨在使组织能够确保可用性并快速响应和适应变化,云原生其实就是一组本质上支持在不同云环境(公共云、私有云或混合云)上大规模构建、运行和管理应用程序的实践和技术。云原生离不开两个概念:容器和微服务,这两个概念是任何云原生应用程序的构建块:微服务是小型、独立的服务(软件)的集合,可以在容器中轻松打包和执行。容器基于容器镜像, 容器是一个标准的软件单元,它打包代码及其所有依赖项,无论基础设施如何, 都允许应用程序快速可靠地运行容器镜像是一个轻量级的、独立的、可执行的软件包,其中包含运行应用程序所需的一切,容器镜像在运行时成为容器使用微服务架构是确保应用程序速度、敏捷性、增长和可用性的基础,因此,它改善了用户体验。例如,随着网络流量的增加或减少,放置在单体专用服务器上的整体应用程序比一组微服务更难扩展和缩减。然而,微服务架构的快速采用导致生产环境中容器数量的增加,这使得容器的管理和维护变得非常困难。并且,如果服务的请求量上来,已部署的服务响应不过来的时候怎么办呢?传统的做法是,如果请求量、内存、C
在上一篇文章中,我分享了有关context包的第一部分:valueCtx和cancelCtx,我们在这篇文章中继续探索更多内容。WithTimeout 和 WithDeadline我们还是先来一个例子:package main import ( "context" "fmt" "time" ) func main() { cancelCtx, cancel := context.WithTimeout(context.Background(), time.Second*3) defer cancel() go task(cancelCtx) time.Sleep(time.Second * 4) } func task(ctx context.Context) { i := 1 for { select { case <-ctx.Done(): fmt.Println(ctx.Err())
背景context在整个Golang生态体系中被广泛使用,我们在平时开发的时候也会经常用到它,而且Golang的很多标准包都依赖它context。关于context的一些使用方法的应用场景我在前面两篇文章也做了详细介绍,今天这篇文章我们就来介绍context内部的源码。我们先回顾一下context它能解决的一些问题:公共参数或数据的传递通知所有子goroutine优雅退出,从而释放资源业务执行超时或者在截止日期之前执行结束,然后程序优雅地退出或返回上面几种使用方法就不做详细的介绍,下面直接看context包的源码。源码分析我们打开context包里面的context.go文件,发现其实除开注释的一些文档外,差不多也就只有200多行的代码。Context接口和emptyCtxcontext最基本的数据结构是Context如下接口:type Context interface { Deadline() (deadline time.Time, ok bool) Done() <-chan struct{} Err() error Value(key i
介绍今天,我们讨论Go编程中context非常重要的一个东西:context超时。我们先简单举个现实生活中的一个场景:想象一下您在一个游乐场,兴奋地想要坐上巨型过山车。但有一个问题:排队的队伍超级长,而且距离游乐场关闭只有一个小时的时间。你该怎么办?嗯,你可能会等一段时间,但不会等一个小时,对吧?如果你等了 30 分钟但仍未排在队伍的前面,你可以离开队列尝试其他的项目。这个例子就是我们所说的“超时”。现在,想象一下你还在排队,突然下起了大雨。游乐场决定关闭过山车。你肯定不会还坚持去排队等待吧?你会马上离开或者去其他地方。这里就是我们所说的“取消”了。在编程里面,我们经常也会遇到类似的情况。要求我们的程序执行可能需要很长时间或由于某种原因需要停止任务。那么这时候context包发挥作用就来了。它可以让我们能够优雅的去处理这些超时和取消。当然我们在上一篇《goroutine并发控制与通信》文章中也讲到了用context去实现多线程的并发控制与通信,这里我们更详细的去介绍context的使用方法。工作原理我们可以分下面几步去模拟上面的场景:首先创建一个上下文,这里和上面场景的去排队过山车类似
序这是Go标准库中的包之一,优雅、功能强大、编写良好且文档齐全。大多数Go开发者的初级阶段都觉得它更令人困惑,就像我在学习Go程序的早期阶段所遇到的那样,迷茫不知道如何上手。原理如下图所示: Golang 中context的入口点是上下文包,它是一个根节点emptyCtx,我们需要的任何上下文(Context)都将是根(emptyCtx)上下文的子级。当需要带有cancel - cancelCtx的上下文时,它实际上会采用父级上下文(空Context),在本例中context.Background()返回的就是一个emptyCtx,并且它将生成以context.Background()作为父级上下文的新上下文,所以我们可以从先前的上下文创建任何上下文作为父上下文,这样就形成了一个图表,也类似于我们常说的树这种数据结构。如果父级上下文被取消(cancel),取消实际上会传播到其所有子级及其子级的所有子级,因此我们在复杂的并发编程中非常有用。应用context中有以下几个场景方法:上面的Background()与TODO()都是空上下文,但是一般我们都使用context.Backgroun
序对于Golang来说,原生支持并发是它的一个强项。并且在项目业务中,很多时候需要用到goroutine去并发的处理业务,多个goroutine之间需要同步与通信,主goroutine需要控制它所属的子goroutine。对于这种情况其实还是很常见的,那么下面我们专门介绍实现多个goroutine间的同步与通信。同步与通信解决方法全局共享变量(共享内存)channel通信(CSP模型)Context包全局共享变量(共享内存)通过一个变量控制所有的子goroutine开始和结束,并不断的去轮询这个变量检查是否有更新,如果子goroutine检测到这个变量有更新就会执行对应的业务逻辑。对于同步与通信来说,共享变量是一个最简单的一个方案,但是在功能上确实有着显著的缺点:全局变量不是线程安全,需要处理竞争关系,所以我们需要对这个变量加锁处理,这样就增加的复杂度,并且过多的锁,容易死锁。排查起来也很困难全局变量传递的数据信息较小,所以它不适用于子goroutine间的通信因为单向通知的原因,主goroutine无法等待所有的子goroutine退出示例:var signal = true fun
青丝南开
文字、摄影、骑行爱好者