云原生技术分享 (二)-摩杜云开发者社区

三、Kubernetes

Kubernetes源于希腊语，意为“舵手”。k8s 缩写是因为 k 和 s 之间有八个字符的原因。它是google在2015开源的容器调度编排的平台。它是建立在Google大规模运行生产工作负载（Borg系统）十几年经验的基础上，结合了社区中最优秀的想法和实践，已经成为了目前容器编排的事实标准。

看到Docker和Kubernetes的Logo，就可以很快明白Kubernetes的作用。Docker的Logo是一条鲸鱼船，运载着许多封装好的集装箱(container)，代表着一次打包到处运行的意图。而Kubernetes的Logo就是这条船的方向舵！

云原生技术分享 (二)_Pod

Kubernetes主要功能：

自我修复：一旦某一个容器崩溃，能够在1秒中左右迅速启动新的容器

弹性伸缩：可以根据需要，自动对集群中正在运行的容器数量进行调整

服务发现：服务可以通过自动发现的形式找到它所依赖的服务

负载均衡：如果一个服务起动了多个容器，能够自动实现请求的负载均衡

版本回退：如果发现新发布的程序版本有问题，可以立即回退到原来的版本

存储编排：可以根据容器自身的需求自动创建存储卷

Kubernetes组件

云原生技术分享 (二)_API_02

控制平面 Master

集群的控制平面，负责集群的决策

ApiServer : 资源操作的唯一入口，接收用户输入的命令，提供认证、授权、API注册和发现等机制。可以理解成 API Server 是 K8S 的所有服务的请求入口。API Server 负责接收 K8S 所有请求（来自 UI 界面或者 CLI 命令行工具），然后根据用户的具体请求，去通知其他组件干活。可以说 API Server 是 K8S 集群架构的大脑。

Scheduler : 负责集群资源调度，按照预定的调度策略将Pod调度到相应的node节点上。可以理解成 K8S 所有 Node 节点的调度器。当用户要部署服务时，Scheduler 会根据调度算法选择最合适的 Node 节点来部署 Pod。

ControllerManager : 负责维护集群的状态，比如程序部署安排、故障检测、自动扩展、滚动更新等。由一系列控制器组成，通过 API Server 监控整个集群的状态，并确保集群处于预期的工作状态，比如当某个 Node 意外宕机时，Controller Manager 会及时发现并执行自动化修复流程，确保集群始终处于预期的工作状态。

Etcd ：负责存储集群中各种资源对象的信息，k/v方式存储，所有的 k8s 集群数据存放在此。

Kubectl: 命令行配置工具。通过命令行执行各种对k8s集群的操作。

数据平面Node

Kubelet : 安装在node上的代理服务，负责维护容器的生命周期，即通过控制docker，来创建、更新、销毁容器，会按固定频率检查节点健康状态并上报给 APIServer，该状态会记录在 Node 对象的 status 中。

Kube-Proxy：安装在Node上的网络代理服务，提供网络代理以及负载均衡，实现与Service通讯。

Docker : 负责节点上容器的各种操作。

Kubernetes其他常用组件

kube-dns负责为整个集群提供DNS服务
Ingress Controller为服务提供外网入口
Heapster提供资源监控
Dashboard提供GUI
Federation提供跨可用区的集群
Fluentd-elasticsearch提供集群日志采集、存储与查询

Pod

云原生技术分享 (二)_Deployment_03

Pod是kubernetes集群进行管理的最小单元，程序要运行必须部署在容器中，而容器必须存在于Pod中。Pod可以认为是容器的封装，一个Pod中可以存在一个或者多个容器。同一个Pod中的容器共享 IP 地址，进程间的通讯，主机名以及其他资源。

pod的生命周期

运行初始化容器（init container）

运行主容器（main container）

容器启动后钩子（post start）、容器终止前钩子（pre stop）

容器的存活性探测（liveness probe）、就绪性探测（readiness probe）

pod终止

云原生技术分享 (二)_Pod_04

Pod的状态：

挂起（Pending）：Pod 已被 Kubernetes 系统接受，但有一个或者多个容器镜像尚未创建。等待时间包括调度 Pod 的时间和通过网络下载镜像的时间，这可能需要花点时间。
运行中（Running）：该 Pod 已经绑定到了一个节点上，Pod 中所有的容器都已被创建。至少有一个容器正在运行，或者正处于启动或重启状态。
成功（Succeeded）：Pod 中的所有容器都被成功终止，并且不会再重启。
失败（Failed）：Pod 中的所有容器都已终止了，并且至少有一个容器是因为失败终止。也就是说，容器以非0状态退出或者被系统终止。
未知（Unknown）：因为某些原因无法取得 Pod 的状态，通常是因为与 Pod 所在主机通信失败。

pod中的容器

云原生技术分享 (二)_API_05

pod内多个容器之间共享的部分：

网络命名空间: IP地址、端口范围、路由表…，同一Pod下容器不能绑定相同端口
UTS命名空间: 主机名，同一Pod下容器拥有相同hostname
IPC命名空间：UNIX域socket

pod内多个容器之间不共享的部分：

容器的文件系统(Mount Namespace)与其他容器完全隔离，但我们可以使用名为volume的Kubernetes资源来共享文件目录

容器的进程空间(PID Namespace)默认与其他容器完全隔离，不过可以设置POD的shareProcessNamespace这个值为true来进行共享

Pod控制器

ReplicaSet(RS)

Kubernetes 中的一个重要组件，它用于确保指定数量的 Pod 副本正在运行

重要特性

Pod 副本数的控制：通过 ReplicaSet，用户可以指定想要的 Pod 副本数目，ReplicaSet 会自动创建或删除 Pod 副本来达到该数量。

根据标签选择器筛选 Pod：ReplicaSet 会基于一组标签选择器来选择匹配的 Pod，以便创建或删除相应的 Pod 副本。标签选择器可以指定某个应用的所有 Pod，也可以根据不同的部署环境来选择特定的 Pod。

确保 Pod 的健康状态：ReplicaSet 会监控所有的 Pod 副本的运行状态，并确保在有 Pod 发生故障时进行恢复。如果某个 Pod 副本意外退出，ReplicaSet 会自动创建一个新的 Pod 副本来代替它，以维持指定的副本数。

滚动更新和回滚：ReplicaSet 还支持滚动更新和回滚操作，用户可以通过指定更新的策略和版本号，对应用程序进行更新和回滚操作。

与其他控制器的协作：ReplicaSet 可以与其他 Kubernetes 控制器对象（如 Deployment）协同工作，来完成应用程序的部署和管理任务。

ReplicaSet 控制器的控制循环过程如下

ReplicaSet 控制器监视 Pod 的状态，确保其与当前 ReplicaSet 配置文件中定义的副本数一致。

数量小于情况：如果当前 Pod 的数量小于 ReplicaSet 配置文件中定义的数量，则 ReplicaSet 控制器会启动新的 Pod 副本来替换当前缺少的 Pod。

数量大于情况：如果当前 Pod 的数量大于 ReplicaSet 配置文件中定义的数量，则 ReplicaSet 控制器会停止一些 Pod 副本，以保持与定义的数量一致

Deployment

Deployment是kubernetes中最常用的资源对象，为ReplicaSet和Pod的创建提供了一种声明式的定义方法，在Deployment对象中描述一个期望的状态，Deployment控制器就会按照一定的控制速率把实际状态改成期望状态，通过定义一个Deployment控制器会创建一个新的ReplicaSet控制器，通过ReplicaSet创建pod，删除Deployment控制器，也会删除Deployment控制器下对应的ReplicaSet控制器和pod资源。

使用Deployment而不直接创建ReplicaSet是因为Deployment对象拥有许多ReplicaSet没有的特性，例如滚动升级和回滚。

云原生技术分享 (二)_Deployment_06

编辑yaml，在spec节点下添加滚动更新策略

strategy:
  type: RollingUpdate #滚动更新策略
  rollingUpdate:
    maxUnavailable: 25%
    maxSurge: 25%

云原生技术分享 (二)_Deployment_07

金丝雀发布

Deployment支持更新过程中的控制，如"暂停（pause）"或"继续（resume）"更新操作。

比如有一批新的pod资源创建完成后立即暂停更新过程，此时，仅存在一部分新版本的应用，主体部分还是旧的版本。然后，再筛选一小部分的用户请求路由到新的pod应用，继续观察能否稳定地按期望的方式运行。确定没问题之后再继续完成余下的pod资源滚动更新，否则立即回滚更新操作。这就是所谓的金丝雀发布。

DaemonSet

DaemonSet类型的控制器可以保证在集群中的每一台（或指定）节点上都运行一个副本。一般适用于日志收集、节点监控等场景。如果一个Pod提供的功能是节点级别的（每个节点都需要且只需要一个），那么这类Pod就适合使用DaemonSet类型的控制器创建。

云原生技术分享 (二)_API_08

DaemonSet控制器的特点：

每当向集群中添加一个节点时，指定的 Pod 副本也将添加到该节点上
当节点从集群中移除时，Pod 也就被垃圾回收了

使用举例：

各种网络插件的 Agent 组件，都必须运行在每一个节点上，用来处理这个节点上的容器网络。

各种存储插件的 Agent 组件，也必须运行在每一个节点上，用来在这个节点上挂载远程存储目录，操作容器的 Volume 目录。

各种监控组件和日志组件，也必须运行在每一个节点上，负责这个节点上的监控信息和日志搜集。

DaemonSet 又是如何保证每个 Node 上有且只有一个被管理的 Pod 呢？

DaemonSet Controller，首先从 Etcd 里获取所有的 Node 列表，然后遍历所有的 Node。这时，它就可以很容易地去检查，当前这个 Node 上是不是有一个携带了 name=fluentd-xxxx 标签的 Pod 在运行

而检查的结果，可能有这么三种情况：

没有这种 Pod，那么就意味着要在这个 Node 上创建这样一个 Pod；

有这种 Pod，但是数量大于 1，那就说明要把多余的 Pod 从这个 Node 上删除掉；

正好只有一个这种 Pod，那说明这个节点是正常的。其中，删除节点（Node）上多余的 Pod 非常简单，直接调用 Kubernetes API 就可以了。

DaemonSet 其实是一个非常简单的控制器。在它的控制循环中，只需要遍历所有节点，然后根据节点上是否有被管理 Pod 的情况，来决定是否要创建或者删除一个 Pod。