Kubernetes

参考文章

1、Kubernetes 概念

Kubernetes 是一个容器集群管理系统 ，为容器化的应用程序提供部署运行、维护 、扩展、资源调度 、服务发现等功能。Kubernetes 是通过对运行的容器的编排来实现构建微服务的

2、Kubernetes 集群

2.0 Kubernetes 架构

• 主节点，它承载着 Kubernetes控制和管理整个集群系统的控制面板。
• 工作节点，它们运行用户实际部署的应用。
  在这里插入图片描述
  
  
  

2.1 Master 节点

Master节点主要还是负责管理和控制。

Master节点包括API Server、Scheduler、Controller manager、etcd。

开发者把一个应用列表提交到主节点， Kubemetes 会将它们部署到集群的工作节点。

2.1.1 API Server

API Server是整个系统的对外接口，供客户端和其它组件调用。

2.1.2 Scheduler

负责对集群内部的资源进行调度。

2.1.3 Controller manager

负责管理控制器

2.1.4 etcd

一个可靠的分布式数据存储，它能持久化存储集群配置。Etcd就是专门为集群环境设计，可以很好地实现数据一致性，提供集群节点状态管理和服务自动发现等。

2.2 Node 节点

Node节点是工作负载节点，Node节点包括Docker、kubelet、kube-proxy、Fluentd、kube-dns（可选），还有就是Pod。

2.2.1 Pod

Pod是Kubernetes最基本的操作单元。一个Pod代表着集群中运行的一个进程，它内部封装了一个或多个紧密相关的容器。

2.2.2 Kubelet

与 API 服务器通信，并管理它所在节点的容器。

2.2.3 Kubernetes Service Proxy

它负责组件之间的负载均衡网络流量。

2.3 Pod 介绍

2.3.1 为何需要pod?

如果在单个容器中运行多个不相关的进程， 那么保持所有进程运行、 管理它们的日志等将
会比较麻烦。因此采用单个容器单个进程，再将多个容器绑定在一起作为一个单元进行处理，就是 pod。

2.3.2 了解 pod

pod 为其内的容器提供几乎相同的环境，这些进程就像运行在一个容器中一样，同时又保持着一定的隔离。pod 中的容器共享主机名和网络接口。一 个 pod 中的容器运行于相同的 etwork 命名空间中， 因此它们共享相同的 IP 地址和端口空间。

每个 pod 都可以通过其他 pod 的 IP 地址来实现相互访问。

2.3.3 通过pod合理管理容器

每个 pod 只包含紧密相关的组件或进程。

Kubemetes 将通过一个静态 IP 地址暴露所有容器，并将该地址暴露给集群中运行的所有应用程序。Kubemetes 监控你的应用程序组件和它们运行的节点，并在节点出现故障时自
动将它们重新调度到其他节点 。

2.3.4 向pod发送请求

2.3.4.1 端口转发

Kubemetes 将允许我们配置端口转发到该pod。可以通过 ip : 本地端口 连接到我们的pod。

2.4 namespace

namespace 使我们能够将不属于 一组的资源分到不重叠的组中。将对象分隔到不同的组，只 允许你对属于特定命名空间的对象进行操作 ， 但实际上命名空间之间并不提供对正在运行的对象的任何隔离 。

命名空间之间是否提供网络隔离取决于 Kubemetes 所使用的网络解决方案。
当该解决方案不提供命名空间间的网
络隔离 时－ ，如果命名空间 f oo 中的某个 po d 知道命名空间 bar 中 pod 的 IP 地址，
那它就可以将流量（ 例如 HTTP 请求）发送到另一个 pod 。

2.5 存活探针

Kubemetes 可以通过存活探针 (liveness probe) 检查容器是否还在运行。

2.5.1 Kubemetes 有以下三种探测容器的机制

1. HTTP GET探针对容器的 IP 地址（你指定的端口和路径）执行 HTTP GET 请求。收到响应，探测成功。返回错误响应状态码或者根本没有响应，探测失败，会重启容器。
2. TCP套接字探针尝试与容器指定端口建立TCP连接。如果连接成功建立，则探测成功。否则，容器重新启动。
3. Exec探针在容器内执行任意命令，并检查命令的退出状态码。如果状态码是0, 则探测成功。所有其他状态码都被认为失败。

2.5.2 创建有效的存活探针

在生产中 运行的pod, 一定 要定义 一 个存 活 探 针。没有探 针的话，Kubemetes无法知道你 的应用是否还活着。 只要进程还在运行， Kubemetes 会认为容器是健康的。

提示：如果你在容器中运行Java应用程序， 请确保使用HTTP GET存活探针，而不是启动全新NM以荻取存活信息的Exec探针。 任何基于NM或类似的应用程序也是如此， 它们的启动过程需要大量的计算资原。

2.6 ReplicationController

ReplicationController会持续监控正在运行的pod列表， 并保证相应 ” 类型” 的pod的数目与期望相符。 如正在运行的pod太少， 它会根据pod模板创建新的副本。如正在运行的pod太多， 它将删除多余的副本。

2.7 ReplicaSet

ReplicaSet 的行为与ReplicationController 完全相同， 但pod 选择器的表达能力更强。它更具表达力的标签选择器。

• 一个 ReplicaSet 可以匹配两组 pod 并将它们视为一个大组。
• ReplicaSet 可以仅基于标签名的存在来匹配 pod 。

2.8 Service 服务

Kubemetes 服务是一种为一组功能相同的 pod 提供单一不变的接入点的资源。当服务存在时，它的 IP 地址和端口不会改变。 客户端通过 IP 地址和端口号建立连接，这些连接会被路由到提供该服务的任意 一个 pod 上。

Kubernetes 服务不是在 HTTP 层面上工作，运行在第四层传输层。服务处理 TCP 和 UDP 包，并不关心其中的载荷内容。因为 cookie 是 HTTP 协议中的一部分，服务并不知道它们，这就解释了为什么会话亲和性不能基千 cookie。

2.9 将服务暴露给外部客户端

1. 将服务的类型设置成NodePort
2. 将服务的类型设置成LoadBalance
3. 创建一 个Ingress资源， 这是 一个完全不同的机制， 通过 一 个IP地址公开多个服务，运行在 HTTP 层（网络协议第 7 层）上，当客户端向 Ingress 发送 HTTP 请求时， Ingress 会根据请求的主机名和路径决定请求转发到的服务。

2.10 Deployment

用千部署应用程序并以声明的方式升级应用，在使用 Deployment 时， 实际的 pod 是由 Deployment 的 Replicaset 创建和管理的， 而不是由 Deployment 直接创建和管理的。

3、Kubernetes 机理

3.1 Kubernetes 架构

3.1.1 控制平面

控制平面负责控制并使得整个集群正常运转。
控制平面包含如下组件：

1. etcd分布式持久化存储
2. API服务器
3. 调度器
4. 控制器管理器

3.1.2 节点

运行容器的任务依赖千每个工作节点上运行的组件：

1. Kubelet
2. Kubelet服务代理( kube-proxy)
3. 容器运行时(Docker、rkt或者其他）

3.1.3 附加组件

1. Kubemetes DNS服务器
2. 仪表板
3. Ingress控制器
4. Heapster (容器集群监控）
5. 容器网络接口插件

3.2 组件间如何通信

Kubemetes系统组件间只能通过API服务器通信， 它们之间不会直接通信。API 服务器是和etcd 通信的唯一组件。 其他组件不会直接和etcd通信， 而是通过 API 服务器来修改集群状态。

3.3 Kubernetes 如何使用 etcd

etcd是一个响应快、 分布式、一致的key-value存储 。因为它 是分布式的，故可以运行多个etcd 实例来获取高可用性和更好的性能。

3.3.1 确保 etcd 集群—致性

为保证高可用性， 常常会运行多个 etcd 实例。 多个 etcd 实例需要保持 一致。etcd 使用 RAFT 一致性算法来保证 一致。

3.3.2 为什么 etcd 实例数量应该是奇数

一致性算法要求集群大部分（法定数量）节点参与才能进行到下一个状态。而 etcd 集群需要超过半数实例处于正常运行状态，etcd 集群才能转换到新状态。

3.4 API服务器做了什么

API服务器除了提供一种 一致的方式将对象存储到 etcd, 也对这些对象做校验，这样客户端就无法存入非法的对象了。

3.5 调度器

利用 API 服务器的监听机制等待新创建的 pod, 然后给每个新的、 没有节点集的 pod 分配节点。

3.6 Kubelet 做了什么

所有 Kubemetes 控制 平面的控制器都运行在主节点上 ， 而 Kubelet 以及 Service Proxy 都运行在工作节点（实际 pod 容器运行的地方〉上 。

Kubelet 就是负责所有运行在工作节点上内容的组件 。

1. 在 API 服务器中创建一个 Node 资源来注册该节点 。
2. 持续监控 API 服务器是否把该节点分配给 pod ， 然后启动 pod 容器 。
3. 持续监控运行的容器，向 API 服务器报告它们的状态、事件和资源消耗 。

3.7 Kubernetes Service Proxy 的作用

确保客户端可以通过 Kubemetes API 连接到你定义的服务 。 如果有多个 pod 支撑一个服务，那么代理会发挥对 po d 的负载均衡作用 。

附录——其他概念介绍

1、蓝绿部署

蓝绿部署中，一共有两套系统：一套是正在提供服务系统，标记为“绿色”；另一套是准备发布的系统，标记为“蓝色”。两套系统都是功能完善的，并且正在运行的系统，只是系统版本和对外服务情况不同。

最初，没有任何系统，没有蓝绿之分。然后，第一套系统开发完成，直接上线，这个过程只有一个系统，也没有蓝绿之分。后来，开发了新版本，要用新版本替换线上的旧版本，在线上的系统之外，搭建了一个使用新版本代码的全新系统。 这时候，一共有两套系统在运行，正在对外提供服务的老系统是绿色系统，新部署的系统是蓝色系统。

蓝色系统不对外提供服务用来做发布前测试，测试过程中发现任何问题，可以直接在蓝色系统上修改，不干扰用户正在使用的系统。（注意，两套系统没有耦合的时候才能百分百保证不干扰）蓝色系统经过反复的测试、修改、验证，确定达到上线标准之后，直接将用户切换到蓝色系统。

切换后的一段时间内，依旧是蓝绿两套系统并存，但是用户访问的已经是蓝色系统。这段时间内观察蓝色系统（新系统）工作状态，如果出现问题，直接切换回绿色系统。当确信对外提供服务的蓝色系统工作正常，不对外提供服务的绿色系统已经不再需要的时候，蓝色系统正式成为对外提供服务系统，成为新的绿色系统。 原先的绿色系统可以销毁，将资源释放出来，用于部署下一个蓝色系统。

蓝绿部署只是上线策略中的一种，它不是可以应对所有情况的万能方案。 蓝绿部署能够简单快捷实施的前提假设是目标系统是非常内聚的，如果目标系统相当复杂，那么如何切换、两套系统的数据是否需要以及如何同步等，都需要仔细考虑。

2、金丝雀发布

只准备几台服务器，在上面部署新版本的系统并测试验证。测试通过之后，担心出现意外，还不敢立即更新所有的服务器。 先将线上的一万台服务器中的10台更新为最新的系统，然后观察验证。确认没有异常之后，再将剩余的所有服务器更新。

全丝雀发布是指在部署新版本时， 先只让一 小部分用户体验新版本以观察新版本的表现， 然后再向所有用户进行推广， 这样可以防止暴露有问题的版本给过多的用户。

实际操作中还可以做更多控制，譬如说，给最初更新的10台服务器设置较低的权重、控制发送给这10台服务器的请求数，然后逐渐提高权重、增加请求数。

金丝雀策略是只有一套系统，逐渐替换这套系统。

3、A/B测试(A/B Testing)

蓝绿部署和金丝雀是发布策略，目标是确保新上线的系统稳定，关注的是新系统的BUG、隐患。

A/B测试是效果测试，同一时间有多个版本的服务对外服务，这些服务都是经过足够测试，达到了上线标准的服务，有差异但是没有新旧之分（它们上线时可能采用了蓝绿部署的方式）。A/B测试关注的是不同版本的服务的实际效果，譬如说转化率、订单情况等。

A/B测试时，线上同时运行多个版本的服务，这些服务通常会有一些体验上的差异，譬如说页面样式、颜色、操作流程不同。相关人员通过分析各个版本服务的实际效果，选出效果最好的版本。