Kubernetes（k8s）

1 k8s 概述

Kubernetes 是一个可移植的、可扩展的开源平台，用于管理容器化的工作负载和服务，可促进声明式配置和自动化。 Kubernetes 拥有一个庞大且快速增长的生态系统。Kubernetes 的服务支持和工具广泛可用。

• kubernetes最初源自于谷歌内部的borg项目，提供了面向应用的容器集群和管理系统。
• k8s目标是消除编排虚拟机，网络和存储等基础设施的负担，并使应用程序运营商和开发人员将重点放在以容器为中心的原语上进行自动运营。
• k8s提供稳定、兼容的基础平台，用于构建定制化的 workflows 和更高级的自动化任务。
• 并且具备完善的集群能力，包括多层次的安全防护和准入机制、多租户应用支撑能力、和透明的服务注册和服务发现机制、内建负载均衡器、故障发现和自我修复能力、服务滚动升级和在线扩容、可扩展的资源自动调度机制、多颗粒的资源配置管理能力。
• 另外，k8s还提供完善的管理工具，涵盖开发、部署测试、运维监控等各个环节。

kubernetes 作为云原生应用的基石，相当于一个云操作系统，重要性由此可见。

1.1 部署方式的演进

1. 传统部署方式：
   在物理服务器上运行应用程序。无法为物理服务器中的应用程序定义资源边界，这会导致资源分配问题。 例如，如果在物理服务器上运行多个应用程序，则可能会出现一个应用程序占用大部分资源的情况， 结果可能导致其他应用程序的性能下降。 一种解决方案是在不同的物理服务器上运行每个应用程序，但是由于资源利用不足而无法扩展， 并且组织维护许多物理服务器的成本很高。

2. 虚拟化部署方式
   虚拟化技术允许你在单个物理服务器的 CPU 上运行多个虚拟机（VM）。 虚拟化允许应用程序在 VM 之间隔离，并提供一定程度的安全。每个 VM 是一台完整的服务器，在虚拟化硬件之上运行所有组件，包括其自己的操作系统。虚拟化技术能够更好地利用物理服务器上的资源，并且因为可轻松地添加或更新应用程序 而可以实现更好的可伸缩性，降低硬件成本等等。但是每个虚拟机都会有操作系统，在资源消耗上，会有所开销。

3. 容器部署方式
   容器类似于 VM，但是它们具有被放宽的隔离属性，可以在应用程序之间共享操作系统（OS）。 因此，容器被认为是轻量级的。容器与 VM 类似，具有自己的文件系统、CPU、内存、进程空间等。 由于它们与基础架构分离，因此可以跨云和 OS 发行版本进行移植。

当前，k8s已经成了容器部署的主流方式，他的优势显而易见的，具体如下：

• 敏捷应用程序的创建和部署：与使用 VM 镜像相比，提高了容器镜像创建的简便性和效率。
• 持续开发、集成和部署：通过快速简单的回滚（由于镜像不可变性），支持可靠且频繁的容器镜像构建和部署。
• 关注开发与运维的分离：在构建/发布时而不是在部署时创建应用程序容器镜像， 从而将应用程序与基础架构分离。
• 可观察性不仅可以显示操作系统级别的信息和指标，还可以显示应用程序的运行状况和其他指标信号。
• 跨开发、测试和生产的环境一致性：在笔记本上与在云中相同地运行。
• 跨云和操作系统发行版本的可移植性：可在 Ubuntu、RHEL、CoreOS、本地、 Google Kubernetes Engine 和其他任何地方运行。
• 以应用程序为中心的管理：提高抽象级别，从在虚拟硬件上运行 OS 到使用逻辑资源在 OS 上运行应用程序。
• 松散耦合、分布式、弹性、解放的微服务：应用程序被分解成较小的独立部分， 并且可以动态部署和管理 - 而不是在一台大型单机上整体运行。
• 资源隔离：可预测的应用程序性能。
• 资源利用：高效率和高密度。

1.2 k8s 的作用

• 服务发现和负载均衡：
  Kubernetes 可以使用 DNS 名称或自己的 IP 地址公开容器，如果进入容器的流量很大， Kubernetes 可以负载均衡并分配网络流量，从而使部署稳定。

• 存储编排：
  Kubernetes 允许你自动挂载你选择的存储系统，例如本地存储、公共云提供商等。

• 自动部署和回滚：
  你可以使用 Kubernetes 描述已部署容器的所需状态，它可以以受控的速率将实际状态 更改为期望状态。例如，你可以自动化 Kubernetes 来为你的部署创建新容器， 删除现有容器并将它们的所有资源用于新容器。

• 自动完成装箱计算：
  Kubernetes 允许你指定每个容器所需 CPU 和内存（RAM）。 当容器指定了资源请求时，Kubernetes 可以做出更好的决策来管理容器的资源。

• 自我修复：
  Kubernetes 重新启动失败的容器、替换容器、杀死不响应用户定义的运行状况检查的容器，并且在准备好服务之前不将其通告给客户端。

• 密钥与配置管理：
  Kubernetes 允许你存储和管理敏感信息，例如密码、OAuth 令牌和 ssh 密钥。 你可以在不重建容器镜像的情况下部署和更新密钥和应用程序配置，也无需在堆栈配置中暴露密钥。

2 k8s 架构

• 在集群管理方面，Kubernets将集群中的机器划分为一个Master节点和一群工作节点(Node)。
• 其中，在Master节点上运行着集群管理相关的一组进程kube-apiserver、kube-controller-manager和kube-scheduler，这些进程实现了整个集群的资源管理、Pod调度、弹性收缩、安全控制、系统监控和纠错等管理功能，并且都是全自动完成的。
• Node作为集群中的工作节点，运行真正的应用程序，在Node上Kubernetes管理的最小运行单元是Pod。
• Node上运行着Kubernetes的kubelet、kube-proxy服务进程，这些服务进程负责Pod创建、启动、监控、重启、销毁、以及实现软件模式的负载均衡。

2.1 k8s 组件

k8s集群包括控制平面组件（也即master节点）和node组件两部分组成。

2.1.1 控制平面组件（Control Plane Components ）

控制平面为集群提供故障转移和高可用性，一般跨多个主机、跨集群运行，对集群做出全局决策(比如调度)，以及检测和响应集群事件（例如，当不满足部署的 replicas 字段时，启动新的pod）。 一般控制平面可以在集群中的任何节点上运行。 然而，为了简单起见，设置脚本通常会在同一个计算机上启动所有控制平面组件，并且不会在此计算机上运行用户容器。

• etcd
  etcd 是兼具一致性和高可用性的键值数据库，可以作为保存 Kubernetes 所有集群数据的后台数据库。etcd最好为集群配置，另外还需对etcd的进行定时备份。

• kube-scheduler
  控制平面调度组件，负责监视新创建的、未指定运行节点（node）的Pods，选择节点让 Pod 在上面运行。调度决策考虑的因素包括单个 Pod 和 Pod 集合的资源需求、硬件/软件/策略约束、亲和性和反亲和性规范、数据位置、工作负载间的干扰和最后时限。

• kube-controller-manager
  在控制平面运行控制器的组件。从逻辑上讲，每个控制器都是一个单独的进程， 但是为了降低复杂性，它们都被编译到同一个可执行文件，并在一个进程中运行。

  这些控制器包括:

  • 节点控制器（Node Controller）: 负责在节点出现故障时进行通知和响应。
  • 副本控制器（Replication Controller）: 负责为系统中的每个副本控制器对象维护正确数量的 Pod。
  • 端点控制器（Endpoints Controller）: 填充端点(Endpoints)对象(即加入 Service 与 Pod)。
  • 服务帐户和令牌控制器（Service Account & Token Controllers）: 为新的命名空间创建默认帐户和 API 访问令牌.

• cloud-controller-manager
  云控制器管理器是指嵌入特定云的控制逻辑的控制平面组件。 云控制器管理器允许您链接聚合到云提供商的应用编程接口中， 并分离出相互作用的组件与您的集群交互的组件。cloud-controller-manager 仅运行特定于云平台的控制回路， 如果在非云环境不需要云控制器管理器。与 kube-controller-manager 类似，cloud-controller-manager 将若干逻辑上独立的控制回路组合到同一个可执行文件中，可以对其执行水平扩容（运行不止一个副本）以提升性能或者增强容错能力。

  对云平台驱动的依赖：

  • 节点控制器（Node Controller）: 用于在节点终止响应后检查云提供商以确定节点是否已被删除
  • 路由控制器（Route Controller）: 用于在底层云基础架构中设置路由
  • 服务控制器（Service Controller）: 用于创建、更新和删除云提供商负载均衡器

2.1.2 node组件

node组件运行在计算的节点服务器，维护运行的 Pod 并提供 Kubernetes 运行环境。

• kubelet
  一个在集群中每个节点（node）上运行的代理。 它保证容器Containers 都运行在Pod中。kubelet 接收一组通过各类机制提供给它的 PodSpecs，确保这些 PodSpecs 中描述的容器处于运行状态且健康。 但kubelet 不会管理不是由 Kubernetes 创建的容器，比如说docker创建的容器。

• kube-proxy
  kube-proxy 是集群中每个节点上运行的网络代理， 实现 Kubernetes 服务（Service）概念的一部分并且维护节点上的网络规则。这些网络规则允许从集群内部或外部的网络会话与 Pod 进行网络通信。若是操作系统提供了数据包过滤层并可用的话，kube-proxy 会通过它来实现网络规则。否则， kube-proxy 仅转发本身流量。

• 容器运行时（Container Runtime）
  容器运行环境是负责运行容器的软件。Kubernetes 支持多个容器运行环境:Docker、 containerd 、CRI-O以及任何实现Kubernetes CRI (容器运行环境接口)。

2.1.3 插件（Addons）

插件使用 Kubernetes 资源（DaemonSet、 Deployment等）实现集群功能。 因为这些插件提供集群级别的功能，插件中命名空间域的资源属于 kube-system 命名空间。插件可分为网络，发现服务，可视化等类别。由于网络插件比较多，讲起来也很晦涩等稍在具体使用在提及，今天介绍下发现服务和可视化两个方面的插件。

• DNS
  尽管其他插件都并非严格意义上的必需组件，但几乎所有 Kubernetes 集群都应该有集群DNS， 因为很多示例都需要 DNS 服务。集群 DNS 是一个 DNS 服务，和环境中的其他 DNS 服务器一起工作，它为 Kubernetes 服务提供 DNS 记录。Kubernetes 启动的容器自动将此 DNS 服务器包含在其 DNS 搜索列表中。

• Web 界面（仪表盘）
  Dashboard是Kubernetes 集群的通用的、基于 Web 的用户界面。 它使用户可以管理集群中运行的应用程序以及集群本身并进行故障排除。

• 容器资源监控
  容器资源监控将关于容器的一些常见的时间序列度量值保存到一个集中的数据库中，并提供用于浏览这些数据的界面。当前比较流行的prometheus和zabbix等都可以做相关监控。

• 集群层面日志
  集群层面日志机制负责将容器的日志数据 保存到一个集中的日志存储中，该存储能够提供搜索和浏览接口，现在做的最好的为ELK系统。

3 k8s Ingress原理

• 官网对 Ingress 的定义为管理对外服务到集群内服务之间规则的集合，通俗点讲就是它定义规则来允许进入集群的请求被转发到集群中对应服务上，从来实现服务暴露。
• Ingress 能把集群内 Service 配置成外网能够访问的 URL，流量负载均衡，及SSL，并提供基于域名访问的虚拟主机等。
• Kubernetes 暴露服务的有三种方式，分别为 LoadBlancer Service、NodePort Service、Ingress。

3.1 LoadBlancer Service

LoadBancer Service 是Kubernetes深度结合云平台的一个组件；当使用LoadBlancer Service 暴露服务时,实际上是通过向底层云平台申请创建一个负载均衡器来向外暴露服务；目前LoadBlancer Service支持的云平台已经相对完善，比如公有云阿里云，华为云及私有云(Openstack)等等，由于LoadBlancer Service深度结合了云平台，所以只能在一些云平台上使用。

3.2 NodePort Service

NodePort Service 是通过在节点上暴漏端口，然后通过将端口映射到具体某个服务上来实现服务暴漏，比较直观方便，但是对于集群来说，随着 Service 的不断增加，需要的端口越来越多，很容易出现端口冲突，而且不容易管理。当然对于小规模的集群服务，还是比较不错的。

3.3 Ingress

Ingress 是在Kubernetes 1.2后出现的，使用开源的反向代理负载均衡器来实现对外暴漏服务，比如 Nginx、Apache、Haproxy等。Nginx Ingress 一般有三个组件组成：

• ingress：是kubernetes的一个资源对象，用于编写定义规则。
• 反向代理负载均衡器：通常以Service的Port方式运行，接收并按照ingress定义的规则进行转发，通常为nginx，haproxy，traefik等。
• ingress-controller，监听api server，获取服务service和pod新增，删除等变化，并结合ingress规则动态更新到反向代理负载均衡器上，并重载配置使其生效。
  
• 实际上请求进行被负载均衡器拦截，比如nginx；
• 然后Ingress Controller通过交互得知某个域名对应哪个Service；
• 再通过跟Kubernetes API交互得知Service地址等信息；
• 综合以后生成配置文件实时写入负载均衡器，然后负载均衡器reload该规则便可实现服务发现，即动态映射。

以 Ingress-nginx 为例：

3.3.1 Ingress-nginx组成

• ingress-nginx-controller：根据用户编写的ingress规则（创建的ingress的yaml文件），动态的去更改nginx服务的配置文件，并且reload重载使其生效（是自动化的，通过lua脚本来实现）。
• ingress资源对象：将Nginx的配置抽象成一个Ingress对象，每添加一个新的Service资源对象只需写一个新的Ingress规则的yaml文件即可（或修改已存在的ingress规则的yaml文件）。

3.3.2 Ingress-nginx工作流程

Ingress 的实现分为两个部分 Ingress Controller 和 Ingress 。

截至目前，nginx-ingress 已经能够完成 7/4 层的代理功能（4 层代理基于 ConfigMap，感觉还有改进的空间）；
Nginx 的 7 层反向代理模式，可以简单用下图表示：

1. Nginx 对后端运行的服务（Service1、Service2）提供反向代理，在配置文件中配置了域名与后端服务 Endpoints 的对应关系。
2. 客户端通过使用 DNS 服务或者直接配置本地的 hosts 文件，将域名都映射到 Nginx 代理服务器。
3. 当客户端访问 service1.com 时，浏览器会把包含域名的请求发送给 nginx 服务器，nginx 服务器根据传来的域名，选择对应的 Service，这里就是选择 Service 1 后端服务，然后根据一定的负载均衡策略，选择 Service1 中的某个容器接收来自客户端的请求并作出响应。

过程很简单，nginx 在整个过程中仿佛是一台根据域名进行请求转发的“路由器”，这也就是7层代理的整体工作流程了！

在 k8s 系统中，后端服务的变化是十分频繁的，单纯依靠人工来更新nginx 的配置文件几乎不可能，nginx-ingress 由此应运而生。Nginx-ingress 通过监视 k8s 的资源状态变化实现对 nginx 配置文件的自动更新，下面本文就来分析下其工作原理。

1. nginx-ingress 模块在运行时主要包括三个主体：NginxController、Store、SyncQueue。
2. Store 主要负责从 kubernetes APIServer 收集运行时信息，感知各类资源（如 ingress、service等）的变化，并及时将更新事件消息（event）写入一个环形管道。
3. SyncQueue 协程定期扫描 syncQueue 队列，发现有任务就执行更新操作，即借助 Store 完成最新运行数据的拉取，然后根据一定的规则产生新的 nginx 配置，（有些更新必须 reload，就本地写入新配置，执行 reload），然后执行动态更新操作，即构造 POST 数据，向本地 Nginx Lua 服务模块发送 post 请求，实现配置更新。
4. NginxController 作为中间的联系者，监听 updateChannel，一旦收到配置更新事件，就向同步队列 syncQueue 里写入一个更新请求。

3.3.3 ingress Pod 漂移问题

Kubernetes 具有强大的副本控制能力，能保证在任意副本（Pod）挂掉时自动从其他机器启动一个新的，还可以动态扩容等，通俗地说，这个 Pod 可能在任何时刻出现在任何节点上，也可能在任何时刻死在任何节点上；那么自然随着 Pod 的创建和销毁，Pod IP 肯定会动态变化；那么如何把这个动态的 Pod IP 暴露出去？这里借助于 Kubernetes 的 Service 机制，Service 可以以标签的形式选定一组带有指定标签的 Pod，并监控和自动负载他们的 Pod IP，那么我们向外暴露只暴露 Service IP 就行了。

3.3.4 ingress 端口管理问题

采用 NodePort 方式暴露服务面临问题是，服务一旦多起来，NodePort 在每个节点上开启的端口会及其庞大，而且难以维护；这时，我们可以能否使用一个Nginx直接对内进行转发呢？众所周知的是，Pod与Pod之间是可以互相通信的，而Pod是可以共享宿主机的网络名称空间的，也就是说当在共享网络名称空间时，Pod上所监听的就是Node上的端口。那么这又该如何实现呢？简单的实现就是使用 DaemonSet 在每个 Node 上监听 80，然后写好规则，因为 Nginx 外面绑定了宿主机 80 端口（就像 NodePort），本身又在集群内，那么向后直接转发到相应Service IP就行了 。如下图所示：