Kubernetes实战(二)——k8s核心概念

从Kubernetes的系统架构、技术概念和设计理念,我们可以看到Kubernetes系统最核心的两个设计理念:一个是容错性,一个是易扩展性。容错性实际是保证Kubernetes系统稳定性和安全性的基础,易扩展性是保证Kubernetes对变更友好,可以快速迭代增加新功能的基础。k8s主要有以下核心概念。

Pods

Pod是Kubernetes的基本操作单元,把相关的一个或多个容器构成一个Pod,通常Pod里的容器运行相同的应用。Pod包含的容器运行在同一个Minion(Host)上,看作一个统一管理单元,共享相同的volumes和network namespace/IP和Port空间。

Kubernetes实战(二)——k8s核心概念

一个Pod中的多个容器应用通常是紧耦合的。Pod在Node上被创建、启动或者销毁。

每个Pod中有一个特殊的Pause容器,其他的成为业务容器,这些业务容器共享Pause容器的网络栈以及Volume挂载卷,因而他们之间的通信及数据交互更为高效。

同一个pod中的业务容器共享如下资源:

  1. PID命名空间(不同应用程序可以看到其他应用程序的PID)

  2. 网络命名空间(pod中多个容器可以访问同一个IP和端口范围)

  3. IPC命名空间(能够使用SystemV IPC或者POSIX消息队列进行通信)

  4. UTS命名空间(共享同一个主机名)

  5. Volumes(访问定义在pod级别的存储卷)

Pod可以单独创建。由于Pods没有可控的生命周期,如果他们进程死掉了,他们将不会重新创建。出于这个原因,建议您使用复制控制器。

Pod其实有两种类型:普通Pod和静态Pod,后者比较特殊,它并不存在Kubernetes的etcd存储中,而是存放在某个具体的Node上的一个具体文件中,并且只在此Node上启动。普通Pod一旦被创建,就会被放入etcd存储中,随后会被Kubernetes Master调度到摸个具体的Node上进行绑定,随后该Pod被对应的Node上的kubelet进程实例化成一组相关的Docker容器冰启动起来,在。在默认情况下,当Pod里的某个容器停止时,Kubernetes会自动检测到这个问起并且重启这个Pod(重启Pod里的所有容器),如果Pod所在的Node宕机,则会将这个Node上的所有Pod重新调度到其他节点上。

Kubernetes实战(二)——k8s核心概念

Services

Services也是Kubernetes的基本操作单元,是真实应用服务的抽象,每一个服务后面都有很多对应的容器来支持,通过Proxy的port和服务selector决定服务请求传递给后端提供服务的容器,对外表现为一个单一访问接口,外部不需要了解后端如何运行,这给扩展或维护后端带来很大的好处。Service通过Label找到Pod组。因为Service是抽象的,所以在图表里通常看不到它们的存在,这也就让这一概念更难以理解。

Kubernetes实战(二)——k8s核心概念

Service具有如下特征:

  1. 拥有一个唯一指定的名字

  2. 拥有一个虚拟IP和端口号

  3. 能够提供某种远程服务能力

  4. 被映射到提供这种服务能力的一组容器上

  5. Service的服务进程目前都基于socket通信方式对外提供服务

Service的服务进程目前都基于socket通信方式对外提供服务,Kubernetes内置了透明的负载均衡以及故障恢复的机制。

要理解Service,首先需要弄明白Kubernetes的三种IP这个问题

  • Node IP:Node节点的IP地址

  • Pod IP: Pod的IP地址

  • Cluster IP:Service的IP地址

 首先,Node IP是Kubernetes集群中节点的物理网卡IP地址,所有属于这个网络的服务器之间都能通过这个网络直接通信。这也表明Kubernetes集群之外的节点访问Kubernetes集群之内的某个节点或者TCP/IP服务的时候,必须通过Node IP进行通信

 其次,Pod IP是每个Pod的IP地址,他是Docker Engine根据docker0网桥的IP地址段进行分配的,通常是一个虚拟的二层网络。

  最后Cluster IP是一个虚拟的IP,但更像是一个伪造的IP网络,原因有以下几点

  • Cluster IP仅仅作用于Kubernetes Service这个对象,并由Kubernetes管理和分配P地址

  • Cluster IP无法被ping,他没有一个“实体网络对象”来响应

  • Cluster IP只能结合Service Port组成一个具体的通信端口,单独的Cluster IP不具备通信的基础,并且他们属于Kubernetes集群这样一个封闭的空间。

Kubernetes集群之内,Node IP网、Pod IP网于Cluster IP网之间的通信,采用的是Kubernetes自己设计的一种编程方式的特殊路由规则。在K8集群中,客户端需要访问的服务就是Service对象。每个Service会对应一个集群内部有效的虚拟IP,集群内部通过虚拟IP访问一个服务。在Kubernetes集群中微服务的负载均衡是由Kube-proxy实现的。Kube-proxy是Kubernetes集群内部的负载均衡器。它是一个分布式代理服务器,在Kubernetes的每个节点上都有一个;这一设计体现了它的伸缩性优势,需要访问服务的节点越多,提供负载均衡能力的Kube-proxy就越多,高可用节点也随之增多。与之相比,我们平时在服务器端做个反向代理做负载均衡,还要进一步解决反向代理的负载均衡和高可用问题。

Kubernetes实战(二)——k8s核心概念Kubernetes实战(二)——k8s核心概念

Replication Controllers

Replication Controller确保任何时候Kubernetes集群中有指定数量的pod副本(replicas)在运行, 如果少于指定数量的pod副本(replicas),Replication Controller会启动新的Container,反之会杀死多余的以保证数量不变。Replication Controller使用预先定义的pod模板创建pods,一旦创建成功,pod 模板和创建的pods没有任何关联,可以修改pod 模板而不会对已创建pods有任何影响,也可以直接更新通过Replication Controller创建的pods。对于利用pod 模板创建的pods,Replication Controller根据label selector来关联,通过修改pods的label可以删除对应的pods。

Kubernetes实战(二)——k8s核心概念

Replication Controller主要有如下用法:

  • Rescheduling

如上所述,Replication Controller会确保Kubernetes集群中指定的pod副本(replicas)在运行, 即使在节点出错时。

  • Scaling

通过修改Replication Controller的副本(replicas)数量来水平扩展或者缩小运行的pods。

  • Rolling updates

Replication Controller的设计原则使得可以一个一个地替换pods来rolling updates服务。

  • Multiple release tracks

如果需要在系统中运行multiple release的服务,Replication Controller使用labels来区分multiple release tracks。

以上三个概念便是用户可操作的REST对象。Kubernetes以RESTfull API形式开放的接口来处理。

Kubernetes实战(二)——k8s核心概念

Kubernetes实战(二)——k8s核心概念

Labels

Labels是用于区分Pod、Service、Replication Controller的key/value键值对,Pod、Service、 Replication Controller可以有多个label,但是每个label的key只能对应一个value。Labels是Service和Replication Controller运行的基础,为了将访问Service的请求转发给后端提供服务的多个容器,正是通过标识容器的labels来选择正确的容器。同样,Replication Controller也使用labels来管理通过pod 模板创建的一组容器,这样Replication Controller可以更加容易,方便地管理多个容器,无论有多少容器。

Kubernetes实战(二)——k8s核心概念

Label Selector在Kubernetes中重要使用场景如下:

  • kube-Controller进程通过资源对象RC上定义Label Selector来筛选要监控的Pod副本的数量,从而实现副本数量始终符合预期设定的全自动控制流程

  • kube-proxy进程通过Service的Label Selector来选择对应的Pod,自动建立起每个Service岛对应Pod的请求转发路由表,从而实现Service的智能负载均衡

  • 通过对某些Node定义特定的Label,并且在Pod定义文件中使用Nodeselector这种标签调度策略,kuber-scheduler进程可以实现Pod”定向调度“的特性

如下图所示,有三个pod都有label为”app=backend”,创建service和replicationController时可以指定同样的label:”app=backend”,再通过label selector机制,就将它们与这三个pod关联起来了。例如,当有其他frontend pod访问该service时,自动会转发到其中的一个backend pod。

Kubernetes实战(二)——k8s核心概念

Kubernetes实战(二)——k8s核心概念

Replica Set

RS是新一代RC,提供同样的高可用能力,区别主要在于RS后来居上,能支持更多种类的匹配模式。副本集对象一般不单独使用,而是作为Deployment的理想状态参数使用。

Deployment

部署表示用户对Kubernetes集群的一次更新操作。部署是一个比RS应用模式更广的API对象,可以是创建一个新的服务,更新一个新的服务,也可以是滚动升级一个服务。滚动升级一个服务,实际是创建一个新的RS,然后逐渐将新RS中副本数增加到理想状态,将旧RS中的副本数减小到0的复合操作;这样一个复合操作用一个RS是不太好描述的,所以用一个更通用的Deployment来描述。以Kubernetes的发展方向,未来对所有长期伺服型的的业务的管理,都会通过Deployment来管理。Deployment集成了上线部署、滚动升级、创建副本、暂停上线任务,恢复上线任务,回滚到以前某一版本(成功/稳定)的Deployment等功能,在某种程度上,Deployment可以帮我们实现无人值守的上线,大大降低我们的上线过程的复杂沟通、操作风险。

Namespace

使用Namespace(命名空间)来组织kubernetes的各种对象,可以实现用户的分组(多租户),对不同的租户还可以进行单独的资源设置和管理,是的整个集群的资源配置非常灵活。

Kubernetes实战(二)——k8s核心概念

Volume

Kubernetes实战(二)——k8s核心概念

  • Volume(容器共享存储卷)

Volume是Pod中能够被多个容器访问的共享目录。Kubernetes的Volume概念与Docker的Volume比较类似,但不完全相同。Kubernetes中的Volume与Pod生命周期相同,但与容器的生命周期不相关。当容器终止或者重启时,Volume中的数据也不会丢失。另外,Kubernetes支持多种类型的Volume,并且一个Pod可以同时使用任意多个Volume。

  • Persistent Volume(持久卷)

Persistent Volume(PV)是集群之中的一块网络存储。跟Node一样,也是集群的资源。PV跟Volume (卷)类似,不过会有独立于Pod的生命周期。这一API对象包含了存储的实现细节,例如NFS、iSCSI或者其他的云提供商的存储系统。

  • Persistent Volume Claims(持久卷申请)

用户通过持久卷请求(PVC)申请存储资源。它跟Pod类似,Pod消费Node的资源,PVC消费PV的资源。Pod能够申请特定的资源(CPU和内存);PVC可以申请大小、访问方式(例如mount rw一次或mount ro多次等多种方式)。

Horizontal Pod Autoscaling

Horizontal Pod Autoscaler(Pod自动扩容)简称HPA,意思是Pod横向自动扩容。可以实现基于CPU使用率的Pod自动伸缩的功能。

与之前的RC、Deployment一样,也属于一种Kubernetes资源对象。通过追踪分析RC控制的所有目标Pod的负载变化情况,来确定是否需要针对性的调整目标Pod数,这是HPA的实现原理。

HPA有两种方式作为Pod负载的度量指标:CPUUtilizationPercentage和应用程序自定义度量指标。

参考:

anzhihe安志合个人博客,版权所有丨 如未注明,均为原创 丨转载请注明转自:https://chegva.com/3033.html | ☆★★每天进步一点点,加油!★★☆

您可能还感兴趣的文章!

发表评论

电子邮件地址不会被公开。 必填项已用*标注