报价宝 › 科技 ›

一文带你深入了解Kubernets(K8s)

报价宝来源：baojiabao.com 发布时间：2019-11-26 16:55:00 10月22日更新

报价宝综合消息一文带你深入了解Kubernets(K8s)

一、Kubernetes 是 Google 团队发起并维护的基于 Docker 的开源容器丛集管理系统，它不仅支援常见的云平台，而且支援内部资料中心。

建于 Docker 之上的 Kubernetes 可以构建一个容器的排程服务，其目的是让使用者透过 Kubernetes 丛集来进行云端容器丛集的管理，而无需使用者进行复杂的设定工作。系统会自动选取合适的工作节点来执行具体的容器丛集排程处理工作。其核心概念是 Container Pod。一个 Pod 由一组工作于同一物理工作节点的容器构成。这些组容器拥有相同的网络名称空间、IP以及储存配额，也可以根据实际情况对每一个 Pod 进行埠对映。此外，Kubernetes 工作节点会由主系统进行管理，节点包含了能够执行 Docker 容器所用到的服务。

二、架构模型为master/nodes(work)

可以理解master为蜂后，nodes为工蜂(干活的)

1. master为丛集唯一入口，需要做高可用。

2. 每一个node节点都提供一部分计算能力和储存能力。(执行容器的节点)

请求过程：

1 客户端请求(建立启动容器)首先发往master，master当中有一个排程器，会去分析各node节点的资源状态.

2 找一个最佳适配执行使用者所请求的容器的节点，并把它排程上去，由这个node的docker或是其他容器引擎来负责把这个容器启动起来。

3 启动容器时检查本地是否有映象，如果没有需要从映象仓库中pull来启动(映象仓库可以是云上的，也可以是自检的私有仓库，也可以以容器执行在node节点上)。

三、Master丛集元件

API Server 接收并处理使用者请求Scheduler 排程容器建立的请求两级排程

第一步：先做预选

1. 评估各node有几个是符合需求的

第二步：再做优选

2. 再从符合需求中的几个选出最优的(优选算法)

> 负责观测每一个node之上总共可用的计算和储存资源，并根据使用者所请求建立的容器所需要的资源量来评估

controller-manager 确保已建立的容器处于健康状态控制器管理器是确保控制器健康的，控制器是用来确保容器健康的。

label selector 可以通过控制器给pod打标签，之后控制器可以根据tag来识别出pod建立pod时可以给pod直接打上一个标签，然后让控制器通过标签的值来识别出pod来

四、Node丛集元件

kubelet 与apiserver互动执行的，接收并处理master排程过来的各种任务。docker 执行pod中的容器1. 在K8s上执行的最小单元不是容器，而是pod

2. kubernets并不直接排程容器，而是排程pod,pod是对容器的一层封装。

3. pod里可以有多个容器，他们共享同一网络协议栈，储存卷

4. 一般一个pod只有一个容器

kube-proxy 与apiserver进行通讯，每一个pod发生变化，结果是需要储存到apiserver中，apiserver会生成一个通知事件，该事件可以被任何关联的组建所接收到，管理service，service的建立及变动是依靠kube-proxy在iptables上创建出规则Pod简介

pod中的每一个容器有自己的user，mnt，pid的名称空间，然后他们共享pod的net,uts,ipc的名称空间。一般一个pod中只有一个容器，除非容器之间有特别特别紧密的关系需要放在同一pod中，如果一个pod放置了多个容器，通常有一个为主容器，其他容器来辅助主容器上的应用程序完成更多功能来实现。建立pod时可以给pod直接打上一个标签，然后让控制器通过标签的值来识别出pod来由于pod为kubernet丛集中的原子单元，是不可再分割的，一个pod中无论是一个容器还是多个容器，当pod被master排程至某一node上时，这个pod中的所有容器都被排程到了一台node上

1. 自主式Pod

自我管理，建立后仍然要提交给apiserver，由apiserver将其排程至指定的node的节点，由node启动此pod，如果一个pod中的容器出现故障，需要重启容器，需要又kubelet来完成。但是，如果节点故障了，该容器就消失了。无法实现全域性进行排程。

2. 控制管理的Pod

正是有控制器机制的引入使得pod成为有生命周期的物件，而后由排程器将其排程至丛集中的某节点执行以后，有一些任务作为守护程序执行为pod或容器，要确保它们随时处于执行状态，一旦发生故障，要随时重启它或者替代它。pod控制器种类

1. Replication Controller

- 多退少补，必须精确符合人定义的期望- 滚动更新（类似使用者无感知释出）- 回滚

2. ReplicaSet

3. Deployment 只能管理无状态应用

4. StatefulSet 管理有状态的应用

5. DaemonSet 每个node上执行一个副本，而不是随意执行

6. Job,Cronjob 执行作业或者周期性作业

- 有些任务是临时需要而执行，执行完以后结束，这种不需要一直处于执行状态，可以执行为一个job

7 . HPA(HorizontalPodAutoscaler) 自动监控并系统负载分析新增或减少pod

服务发现功能

每重新生成一个pod都是一个全新的pod，比如ip地址和主机名之前的是不一样的。kubernets为每一组提供同类服务的pod和它的客户端之间添加了一个中间层，这个中间层（service）是固定的，service再将客户端请求埠代理至后端pod上(通过dnat规则 )，一旦其中一个pod宕机了，一个新的pod会立即被关联上来(通过标签选择器，具有相同标签的来关联起来)，然后在动态探测新关联的pod的ip地址和主机名，

五、k8s网络模型

1. pod网络。各pod执行在同一个网络，pod的网络地址是真实的地址，存在于它的网络名称空间当中。

2. service网络（丛集网络）。service地址不是真的地址，存在于iptables中或者ipvs规则中。

3. 节点网络。

六、k8s通讯分类

1. 同一pod内的多个容器间：lo网络

2. 各pod之间通讯。(overlay network，叠加网络)

各pod之间直接通讯，无论pod执行在哪个节点之上，各pod的地址是不应该也绝对不可以相同。

3. pod与servic之间通讯

service地址只不过是主机上的一条iptables规则中的地址，所以需要配置一下目标地址不是自己的指向闸道器。每个主机上都应该有所有的service的地址规则。当pod试图访问service的地址时，首先将请求送给闸道器（一般为docker0桥），然后docker0桥通过核心发现当前访问的地址为一条iptables或ipvs规则，然后将请求送达。

之前说过，当service后端的node节点宕机，pod的控制器通过标签选择器会自动建立一个新的pod并加入至该服务中，而node中的另一个元件，kube-proxy 在此时会将service的变动储存在master上的api server中，然后api server生成通知事件，又kube-porxy将iptables规则的变化反映至每一个节点的iptables规则上。