Kubernetes概览

原文链接：🌐 n1-Kubernetes名称概念解释一览|WeiyiGeek Blog|唯一极客Geek-IT网络安全运维开发技术知识分享-博客站点

什么是Kubernetes？

Kubernetes（k8s）是自动化容器操作的开源平台，这些操作包括部署，调度和节点集群间的扩展。不仅支持Docker还支持Rocket容器技术。

Kubernetes功能？

1，自动化容器的部署和复制
2，随时扩展或收缩容器规模
3，将容器组织成组，并且提供容器间的负载均衡
4，很容易地升级应用程序容器的新版本
5，提供容器弹性，Node节点故障业务系统的自动恢复，容器失效替换等

K8s与vSphere之间的对比：

1，对于虚拟机来讲述：vSphere平台为虚拟机准备好运行环境，而k8s则是为容器准备好运行环境。
2，对于存储数据库来讲述：在vSphere中有一个vCenter DB里面存放了集群中所有虚拟机以及集群有关的信息；而k8s采用的是etcd数据库用来持久化存储k8s集群中所有的资源的信息。
3，在vSphere虚拟化平台中，vCenter相当于主节点/管理节点/控制节点，是一个控制平面，而ESXi主机则是工作节点/虚拟机工作的节点，是应用负载的一个平面。
4，k8s中的master节点和vCenter的角色一样，也是主节点/管理节点/控制节点，是一个控制平面，k8s中的node节点和ESXi主机一样是工作节点/Pod/容器运行的节点，是一个应用负载的平面。

Cluster集群

描述：集群是一组节点，这些节点可以是物理服务器或者虚拟机，之上安装了K8s平台

K8s架构图

Master节点

描述：k8s master节点提供集群的独特视角，集群需要一个以上的master节点。

1，Kube-apiserver

描述：api-server是k8s控制面板的前端，主节点上负责提供k8s API服务的组件。api-server作为k8s最核        心的组件，其他组件（kubelet,kubectl,调度器，控制器管理器等）都会去调用它。
应用场景：1，API-Server以RESTFUL API 的形式提供了可以查询，修改集群状态的CRUD接口，使其将这些对集群中各种资源的增删改查的状态存储到etcd中。
        2，API-Server为k8s中系统组件间提供交流的平台，并且是与etcd通信的唯一组件，其他组件不会直接和etcd通信，而是通过API来修改集群状态。
        3，API-Server提供可以用来和集群交互的REST端点。
鉴权：1，API服务器接收到的请求会经过一个认证插件的列表，列表中的每个插件都可以检查这个请求和尝试确定谁在发送这个请求。
        2，列表中的第一个插件可以提取请求中客户端的用户名，用户id和信息组，并返回给API服务器。
        3，API服务器会停止调用剩余的认证插件并继续进入授权阶段。授权通过的话才允许创建允许的资源。

 2，kube-scheduler

描述：该组件运行在master节点之上监视那些新创建的未指定运行节点的Pod，并选择节点让Pod在上面运行。

操作：1，宏观来看调度器的操作比较简单，就是利用APIServer的监听机制等待新创建的Pod然后给每个新的，没有节点的Pod分配节点。
    2，调度器不会命令选中的节点（或者节点上运行的Kubelet）去运行Pod，首先通过API-server更新Pod的定义然后API-server再去通知Kubelet，当目标节点上的Kubelet发现该Pod被调度到本节点，它就会创建并且运行Pod容器。

调度器查找可用节点需要检查的关键项：
    1，节点是否满足硬件需求
    2，节点是否已经耗尽资源
    3，Pod是否配置了nodeSelector
    4，Pod是否配置了nodePord,节点是否满足
    5，如果Pod有PVC需求，该节点是否可以挂载PVC
    6，该节点是否有污点，Pod是否能接收
    7，该节点是否满足Pod的affnity配置
    8，可以通过定义Pod的亲缘性，非亲缘性规则强制Pod分散在集群内或者集中在一起
    9，Pod会使用默认调度器进行调度，也可以配置Pod中的schedulerName来设置指定的调度器

3，kube-controller-manager

描述：Api-Server只做了存储资源到etcd和通知客户端有变更的工作。调度器则只是给Pod分配节点，所以需要有活跃的组件确保系统真实状态和API服务器定义的期望的状态的一致，该工作由控制管理器来实现。

工作原理：1，K8s内部的控制工作都通过APIServer这一声明式的数据存储进行了解耦，而控制器就是保持各个不同资源间一致性的一种异步的管理工具。
        2，通过APIServer监听各自负责的资源，一旦自愿发生变化，控制器就负责修改相应的资源，确保各个类型的资源间保持一致。
        3，控制器实际上不做任何具体的操作，只是通过APIServer监听指定的资源，修改相关的其他资源。

功能：通过API服务器监听资源（部署，服务）变更，并且不论新建，更新，删除等操作，都对变更执行相应操作。这些操作涵盖了新建其他资源或者更新监听的资源本身。
        1，总的来说，控制器执行一个调和循环，将实际状态调整为期望状态，然后将新的实际状态写入资源的status部分。控制器利用监听机制来订阅变更，但是由于使用监听机制并不保证控制器不会漏掉时间，所以仍然需要定期执行重列举操作来确保不会丢掉什么。
        2，所有这些控制器都是通过APIServer来操作API对象的，它们不会直接和kubelet通信或者发送任何类型的指令。控制器更新APIServer的一个资源后，kubelet会负责做它该做的事，kubelet通过监听APIserver获取变更，所以Kubelet和控制器都不知道对方的存在。

包含类型：Deployment Controller, Job Controller, StatefulSet Controller, DaemonSet Controller

4，Replication Controller

描述：Replication Controller确保任意时间都有指定数量的Pod副本在运行。

创建条件：1，Pod模版，用来创建Pod副本的模版，从而进行手动创建Pod
        2,Label,Replication Controller需要监控的Pod标签。现在已经创建了Pod的一些副本，那么在这些副本上如何负载均衡？我们需要的是Service.

特点：1，如果为某个Pod创建了Replication Controller并指定了3个副本，它会创建三个Pod,并且持续监控他们。
      2，如果某个Pod不响应了，那么RC会替换他，保持Pod总数为3
      3，如果之前不响应的Pod恢复了，那么现在就有4个了，那么RC会删除其中的一个，保持总数为3
      4，如果在运行中将副本数改为5，RC会立即启动2个新的Pod，保证总数为5

 Worker 节点

描述：worker节点是K8s中的工作计算机，可以是VM或者物理机。多个Pod可以运行在一个节点上。由master节点管理。

比如下图显示一个Node包含4个Pod

 补充：一个Node可以有多个Pod,master根据每个Node上可用资源的情况自动调度Pod到最佳的Node上。每个Node至少运行Kubelet以及容器运行环境负责下载镜像，创建和运行容器等。

1，Kubelet

描述：负责master和worker节点之间通信的进程。管理Pod和Pod内运行的Container;简单的说，kubelet就是负责所有运行在工作节点上内容的组件。

任务：1，在API服务器中创建一个Node资源来注册该节点。
     2，持续监控API服务器是否把该节点分配给Pod然后启动容器。
     3，持续监控运行的容器，向API服务器报告他们的状态，事件和资源消耗。
     4，运行容器存活探针的组件，当探针报错时重启容器。
     5，基于API服务器/本地文件目录中的Pod定义运行Pod，当Pod从API服务器删除时，kubelet终止容器，并通知服务器Pod已经被终止。

2，Kube-proxy

描述：运行在每个工作节点上。确保客户端可以通过Kubernetes API连接到你定义的服务。kube-proxy确保对服务IP和端口的连接最终能到达支持服务的某个Pod,如果有多个Pod他还将负责负载均衡。

功能：1，kube-proxy服务监控k8s集群的service和endpoint对象，当这两个资源对象有状态变化时，会把它们保存在ServiceMap和EndPointMap中，然后通过async.BoundedFrequencyRunner去异步执行syncProxyRules去下发规则。
     2，userspace代理：通过修改iptables让连接到达kube-proxy再转发到Pod
     3，iptables代理：通过修改iptables让连接直接到达Pod
     4，ipvs代理：IPVS是一个用于负载均衡的Linux内核功能，IPVS模式下kube-proxy使用IPVS负载均衡代替了iptables

kube-proxy在使用iptables和ipvs实现对Service的负载均衡区别？
    1，Iptables实现方式：由于Iptable本身的特性 新增规则，更新规则是非增量式的，需要显iptables-save然后在内存中更新规则。在内核中修改规则在iptables-restore并且iptables在进行规则查找匹配时是线性查找耗费时间长。
    2，IPVS实现方式：链接过程的复杂度为O(1)，基本就是说连接的效率和集群的Service的数量无关，因此随着集群内部的Service的不断增加，IPVS的性能优势就体现出来了。

3，Pod

描述：Pod是K8s中的一个抽象的概念，他是集群上的最基本的单元且总是在Node节点上运行，用于存放应用程序实例的container，可以包含一个或多个container以及这些container的一些共享资源。

Pod和容器之间的关系？
容器的设计原则就是为了隔离，即在单一的容器内运行单一的进程，而Pod将这些单一的进程聚集在一起。从某种程度上来说这样的Pod就像是运行多个进程的操作系统，而比操作系统更加轻量。

共享资源包括什么？
1，网络：每个Pod在集群中有唯一的IP,且Pod中的container共享该IP地址；
2，共享存储：卷，Volumes；
3，容器信息：例如容器的镜像版本，对外暴露的端口等；

补充说明：
1，每个Pod都与运行他的worker节点绑定，并保持在那里直到终止或被删
2，每个Pod中运行着一个特殊的被称为Pause的容器，其他则为业务容器
3，简单的说，Pod是一组容器，以及共享存储，IP地址，和有关如何运行容器的信息。将应用的容器，存储资源，独立网络IP,等资源打包到一起
4，Pod内的容器都可以访问共享的存储和网络
5，每一个Pod中的运行的容器可能不止一个。因为设计之初就是为了同一个Pod内的容器能够共享存储和网络，方便多个进程之间进行协调，从而构建出一个高内聚的服务单元。

 

示例：假定有2个后台Pod,并且定义后台Service的名称为backend-service，label选择器为tier=backend,app=myapp的service会完成如下两件重要的事情：
    1，为Service创建一个本地集群的DNS入口，因此前端的Pod只需要DNS查找主机名为backend-service，就能够解析出前端应用程序的IP地址
    2，现在前端已经得到了后台服务的IP地址但是由于有两个后台Pod，Service在这两个后台Pod之间提供透明的负载均衡，会将请求分发给其中的任意一个。

注意事项：
    1，如果多个容器紧密耦合并且需要共享磁盘等资源，则它们应该被部署在同一个Pod
    2，如果节点发生故障，则会在集群中的其他可用节点上运行相同的Pod,从同样的镜像创建container，使用同样的配置但是IP地址不通，Pod名字不同
    3，由于Pod中的容器共享Ip地址和端口空间，即同一个Pod的容器可以使用localhost+端口互相访问，Pod内的容器端口不能冲突。

下面展示Service的功能

 F&Q

1,如果Pod是短暂的，那么我们怎么才能持久化容器数据使其能够一直存在呢？
    
    K8s支持持久卷的概念，可以使用持久化的类型

2,是否手动创建Pod，如果想要一个Pod的多份拷贝，需要一个一个的创建吗？
    
    可以手动创建。也可以使用RC使用Pod模版创建出多份拷贝

3,如果Pod是短暂的，那么重启时IP地址会改变，怎么才能从前端容器正确可靠的指向后台容器呢？

    使用Service

4，Service

描述：Service是分布式集群架构的核心，并且k8s中的Service提供了这样一个抽象层，它选择具备某些特征的Pod并为它们定义一个访问方式。它通过LabelSeletor选择了一组Pod，把这些Pod的指定端口公布到集群外部，并支持负载均衡和服务发现。

作用：1，使Pod之间的相互依赖解耦，原本从一个Pod中访问另一个Pod,需要知道对方的IP,公布Pod的端口以事其可访问

示例：下图中有两个服务Service A(黄色虚线)，Service B(蓝色虚线)

Service A 将请求转发到Ip为10.10.10.1的Pod上

Service B将请求转发到Ip为10.10.10.2，10.10.10.3，10.10.10.4的Ip上

 

补充：

1，一个Service选定哪些Pod通常由LabelSelector来决定

2，Service将外部请求路由到一组Pod中，使K8s可以在不影响服务调用者的情况下，动态调度容器组，在容器组失效后重新创建容器组，增加或者减少同一个Deployment对英容器租的数量等

5，Labels

描述：通过Deployment的yaml文件中配置Labels标签，可以灵活定位一个或多个资源；Label是attach到Pod的一对键值对组成，用来传递用户定义的属性，可以使用Selectors选择带有特定Label的Pod，并且将Service或者RC应用到上面

示例：你可能创建了一个tier和app的标签，通过Label(tier=frontend, app=myapp)来标记前端Pod容器，使用Label(tier=backend,app=myapp)来标记后台Pod

补充：
    利用Service将多个Node节点的Pod中的相通的标签容器进行关联，以便于提供负载均衡；同时也方便用户根据标签查询过滤应用

6，LabelSelector

描述：Service使用Labels,LabelSelector匹配一组Pod,Labels是附加到K8s对象的键值对。

用途：1，将k8s对象Node,Deployment,Pod,Service，指派用于开发环境，测试环境或者生产环境
     2，嵌入版本标签，使用标签区别不同应用软件版本
     3，使用标签对K8s对象进行分类

示例：下图体现了Labels和BabelSelector之间的关系

Deployment B含有LabelSelector为app=B通过此方式声明含有app=B标签的Pod与之关联

Service B 通过标签选择器app=B选择可以路由的Pod

补充：

1，Labels可以在创建k8s对象附加上去，也可以创建之后再加

2，任何时候都可以修改一个K8s对象的Labels

 网络模型

图解：1，通过api-server监控服务以及端点，通过kube-proxy代理设置负载规则

           2，客户端通过iptables实现的负载均衡重定向到kube-proxy代理，最终代理到后端的Pod中

F&Q

K8s与容器的历程

K8s在初期版本中，对多个容器引擎做了兼容，因此可以使用docker,rtk对容器进行管理，以docker为例，kubelet会启动一个docker manager，通过直接调用docker的api进行容器的创建等操作。

在k8s 1.5版本之后，k8s推出自己的运行时接口api-CRI。CRI接口的推出，隔离了各个容器引擎之间的差异，而通过统一的接口与各个容器引擎之间进行互动。

与OCI不同，CRI与k8s的概念更加贴合，并紧密绑定。CRI不仅定义了容器的生命周期的管理，还引入了k8s中Pod的概念，并定义了管理Pod的生命周期。在k8s中，Pod是由一组进行了资源限制的/在隔离环境中的容器组成。而这个隔离环境，称之为PodSandbox。在CRI开始之初，主要是支持docker,rkt两种。其中kubelet是通过cri接口调用docker-shim，并进一步调用docker api实现的。

如上文，docker独立出来的了containerd。k8s也顺应潮流孵化了cri-containerd项目，用以将container接入到cri标准中。

为了进一步与OCI兼容，k8s还孵化了cri-o，成为了架设在CRI和OCI之间的一座桥梁。通过这种方式，可以方便的更多符合OCI标准的容器运行时，接入K8s进行集成使用。可以遇见到，通过CRI-O,K8s在使用的兼容性和广泛性上将会得到进一步加强。

K8s与CRI与Docker-manager的关系图