kubernetes 理论基础知识

什么是 kubernetes？

Kubernetes 是容器集群管理系统，是一个开源的平台，可以实现容器集群的自动化部署、自动扩缩容、维护等功能。

使用 Kubernetes 可以：

• 自动化容器的部署和复制
• 随时扩展或收缩容器规模
• 将容器组织成组，并且提供容器间的负载均衡
• 很容易地升级应用程序容器的新版本
• 节省资源，优化硬件资源的使用
• 提供容器弹性，如果容器失效就替换它，等等...

kubernetes 特点

• 便携性：支持公有云、私有云、混合云、多重云 (multi-cloud)
• 可扩展：模块化、插件化、可组合、可挂载
• 自修复：自动部署，自动重启，自动复制，自动伸缩扩展

kubernetes 特性

Kubernetes 是一种用于在一组主机上运行和协同容器化应用程序的系统，旨在提供可预测性、可扩展性与高可用的性的方法来完全管理容器化应用程序和服务的生命周期的平台。

它具有以下几个重要的特性：

1. 自动装箱：构建于容器之上，基于资源依赖及其他约束自动完成容器部署且不影响其可用性，并通过调度机制混合关键型应用和非关键型应用的工作负载于同一节点以提升资源利用率。
2. 自我修复：支持容器故障后自动重启、节点故障候重行调度容器，以及其他可用节点、健康状态检查失败后关闭容器并重新创建等自我修复机制。
3. 水平扩展：支持通过简单命令或 UI 手动水平扩展，以及基于 CPU 等资源负载率的自动水平扩展机制。
4. 服务器发现和负载均衡：Kubernetes 通过其附加组件之一的 KubeDNS（或 CoreDNS） 为系统内置了服务发现功能，它会为每个 Service 配置 DNS 名称，并允许集群内的客户端直接使用此名称发出访问请求，而 Service 则通过 iptables 或 ipvs 内建了负载均衡机制。
5. 自动发布和回滚：Kubernetes 支持 「灰度」 更新应用程序或其配置信息，它会监控更新过程中应用程序的健康状态，以确保它不会在同一时刻杀掉所有的实例，而此过程中一旦有故障发生，就会立即自动执行回滚操作。
6. 秘钥和配置管理：Kubernetes 允许存储和管理敏感信息，例如密码，Oauth 令牌和 ssh 秘钥。可以部署和更新密码和应用程序配置，而无需重建容器，也不会再堆栈配置中暴露机密。
7. 存储编排：Kubernetes 支持 Pod 对象按需自动挂载不同类型的存储系统，这包括节点本地存储、公有云服务商的云存储 （如 AWS 和 GCP 等），以及网络存储系统 （例如，NFS、ISCSI、GlusterFS、Ceph、Cinder 和 Flocker 等）
8. 批量处理执行：除了服务型应用，Kubernetes 还支持批处理作业及 CI（持续集成），如果需要，一样可以实现容器故障后修复。

kubernetes 概述和术语

Kubernetes 使用共享网络将多个物理机或虚拟机汇集到一个集群中，在各服务器之间进行通信，该集群是配置 Kubernetes 的所有组件、功能和工作负载的物理平台。集群中一台服务器 （或高可用部署中的一组服务器） 用作 Master，负责管理整个集群，余下的其他机器用作 Worker Node, 它们是使用本地和外部资源接收和运行工作负载的服务器。集群中的这些主机可以是物理服务器，也可以是虚拟机 （包括 IaaS 云端的 VPS）

• Master

Master 是集群的网关和中枢，负责诸如为用户和客户端暴露 API、跟踪其它服务器的健康状态、以最优方式调度工作负载，以及编排其他组件之间的通信等任务，它是用户或客户端与集群之间的核心联络点，并负责 Kubernetes 系统的大多数集中式管控逻辑。单个 Master 节点即可完成其所有的功能，但出于冗余及负载均衡等目的，生产环境中通常需要协同部署多个此类主机。Master 节点类似于蜂群中的蜂王

• Node

Node 是 Kubernetes 集群的工作节点，负责接收来自 Master 的工作指令并根据指令相应的创建或删除 Pod 对象，以及调整网络规则以合理地路由和转发流量等。理论上讲，Node 可以是任何形式的计算设备，不过 Master 会统一将其抽象为 Node 对象进行管理。Node 类似于蜂群中的工蜂，生产环境中，它们通常数量众多。

Kubernetes 将所有 Node 的资源集结于一处形成一台更强大的 「服务器」，如下图，在用户将应用部署于其上时，Master 会使用调度算法将其自动指派某个特定的 Node 运行，在 Node 加入集群或从集群中移除时，Master 也会按需重行编排影响到的 Pod（容器）。于是，用户无需关心其应用究竟运行于何处。

从抽象的角度来讲，Kubernetes 还有着众多的组件来支撑其内部的业务逻辑，包括运行应用、应用编排、服务暴露、应用恢复等，它们在 Kubernetes 中被抽象为 Pod、Service、Controller 等资源类型。

常用的资源对象

• Pod

Kubernetes 并不直接运行容器，而是使用一个抽象的资源对象来封装一个或者多个容器，这个抽象即为 Pod，它是 Kubernetes 的最小调度单元。同一 Pod 中的容器共享网络名称空间和存储资源，这些容器可经由本地回环接口 lo 直接通信，但彼此之间又在 Mount、User 及 PID 等名称空间上保持了隔离。尽管 Pod 中可以包含多个容器，但是作为最小调度单元，它应该尽可能地保持 「小」，即通常只应该包含一个主容器，以及必要的辅助型容器 （sidecar）

• 资源标签

标签 （Label） 是将资源进行分类的标识符，资源标签其实就是一个键值型 （key/values） 数据。标签旨在指定对象 （如 Pod 等） 辨识性的属性，这些属性仅对用户存在特定的意义，对 Kubernetes 集群来说并不直接表达核心系统语意。标签可以在对象创建时附加其上，并能够在创建后的任意时间进行添加和修改。一个对象可以拥有多个标签，一个标签也可以附加于多个对象 （通常是同一类对象） 之上。

• 标签选择器

标签选择器 （Selector） 全称为」Label Selector「，它是一种根据 Label 来过滤符合条件的资源对象的机制。例如，将附有标签」role：backend「的所有 Pod 对象挑选出来归为一组就是标签选择器的一种应用，如下图所示，通常使用标签对资源对象进行分类，而后使用标签选择器挑选出它们，例如将其创建未某 Service 的端点。

• Pod 控制器

尽管 Pod 是 kubernetes 的最小调度单元，但用户通常并不会直接部署及管理 Pod 对象，而是要借助于另一类抽象——控制器 （Controller） 对其进行管理。用于工作负载的控制器是一种管理 Pod 生命周期的资源抽象，它们是 kubernetes 上的一类对象，而非单个资源对象，包括 ReplicationController，ReplicaSet、Deployment、StatefulSet、Job 等。已下图所示的 Deployment 控制器为例，它负责确保指定的 Pod 对象的副本数量精确符合定义，否则 「多退少补」。使用控制器之后就不再需要手动管理 Pod 对象了，只需要声明应用的期望状态，控制器就会自动对其进行进程管理。

• 服务资源 （Service）

Service 是建立在一组 Pod 对象之上的资源抽象，它通过标签选择器选定一组 Pod 对象，并为这组 Pod 对象定义一个统一的固定访问入口 （通常是一个 IP 地址），若 Kubernetes 集群存在 DNS 附件，它就会在 Service 创建时为其自动配置一个 DNS 名称以便客户端进行服务发现。到达 Service IP 的请求将被负载均衡至其后的端点——各个 Pod 对象之上，因此 Service 从本质上来讲是一个四层代理服务。另外，service 还可以将集群外部流量引入到集群中来。

• 存储卷

存储卷 （Volume） 是独立于容器文件系统之外的存储空间，常用于扩展容器的存储空间并为它提供持久存储能力。Kubernetes 集群上的存储卷大体可以分为临时卷、本地卷和网络卷。临时卷和本地卷都位于 Node 本地，一旦 Pod 被调度至其他 Node，此种类型的存储卷将无法访问到，因此临时卷和本地卷通常用于数据缓存，持久化的数据则需要放置于持久卷 （persistent volume） 之上。

• Name 和 Namespace

名称 （Name） 是 Kubernetes 集群中资源对象的标识符，它们的作用域通常是名称空间 （Namespace），因此名称空间是名称的额外的限定机制。在同一名称空间中，同一类型资源对象的名称必须具有唯一性。名称空间通常用于实现租户或项目的资源隔离，从而形成逻辑分组，如下图所示，创建的 Pod 和 Service 等资源对象都属于名称空间级别，未指定时，他们都属于默认的名称空间 「default」。

• Annotation

Annotation（注释） 是另一种附加在对象之上的键值类型的数据，但它拥有更大的数据容量。Annotation 常用于将各种非标识型元数据 （metadata） 附加到对象上，但它不能用于标识和选择对象，通常也不会被 Kubernetes 直接使用，其主要目的是方便工具或用户的阅读和查找等。

• Ingress

Kubernetes 将 Pod 对象和外部网络环境进行了隔离，Pod 和 Service 等对象间的通信都使用其内部专用地址进行，如若需要开放某些 Pod 对象提供给外部用户访问，则需要为其请求流量打开一个通往 Kubernetes 集群内部的通道，除了 Service 之外，Ingress 也是这类通道的实现方式之一。

kubernetes 集群组件

Master 组件

Kubernetes 的集群控制平面由多个组件组成，这些组件可统一运行于单一 Master 节点，也可以以多副本的方式同时运行于多个节点，以为 Master 提供高可用功能，甚至还可以运行于 Kubernetes 集群自身之上。Master 主要包括以下几个组件。

1. API Server

Api Server 负责输出 RESTful 风格的 Kubernetes API，它是发往集群的所有 REST 操作命令的接入点，并负责接收、校验并响应所有的 REST 请求，结果状态被持久存储于 etcd 中。因此，API Server 是整个集群的网关。

2. ETCD

Kubernetes 集群的所有状态信息都需要持久存储于存储系统 etcd 中，不过，etcd 是由 CoreOS 基于 Raft 协议开发的分布式键值存储，可用于服务发现、共享配置以及一致性保障 （例如数据库主节点选择、分布式锁等）。因此，etcd 是独立的服务组件，并不隶属于 Kubernetes 集群自身。生产环境中应该以 etcd 集群的方式运行以确保其服务可用性。

etcd 不仅能够提供键值数据存储，而且还为其提供了监听 （watch） 机制，用于监听和推送变更。Kubernetes 集群系统中，etcd 中的键值发生变化时会通知到 API Server，并由其通过 watch API 向客户端输出。基于 watch 机制，Kubernetes 集群的各组件实现了高效协同。

3. Controller Manager

Kubernetes 中，集群级别的大多数功能都是由几个被称为控制器的进程执行实现的，这几个进程被集成与 kube-controller-manager 守护进程中。由控制器完成的功能主要包括生命周期功能和 API 业务逻辑，具体如下

• 生命周期功能：包括 Namespace 创建和生命周期、Event 垃圾回收、Pod 终止相关的垃圾回收、级联垃圾回收及 Node 垃圾回收等。
• API 业务逻辑：例如，由 ReplicaSet 执行的 Pod 扩展等。

4. Scheduler

Kubernetes 是用于部署和管理大规模容器应用的平台，根据集群规模的不同，其托管运行的容器很可能会数以千计甚至更多。API Server 确认 Pod 对象的创建请求之后，便需要由 Scheduler 根据集群内各节点的可用资源状态，以及要运行的容器的资源需求做出调度决策，如下图所示。另外，Kubernetes 还支持用户自定义调度器。

Node 组件

Node 负责提供运行容器的各种依赖环境，并接收 Master 的管理。每个 Node 主要由以下几个组件构成。

• kubelet

kubelet 是运行于工作节点之上的守护进程，它从 API Server 接收关于 Pod 对象的配置信息并确保它们处于期望的状态 （desired state，也可以说目标状态）kubelet 会在 API Server 上注册当前工作节点，定期向 Master 汇报节点资源使用情况，并通过 cAdvisor 监控容器和节点的资源占用情况。

• kube-proxy

每个工作节点都需要运行一个 kube-proxy 守护进程，它能够按需为 Service 资源对象生成 iptables 或 ipvs 规则，从而捕获访问当前 Service 的 ClusterIP 的流量并将其转发至正确的后端 Pod 对象。

• docker

docker 用于运行容器

核心附件

Kubernetes 集群还依赖于一组称为" 附件"(add-ons) 的组件以提供完整的功能，它们通常是由第三方提供的特定应用程序，且托管运行于 Kubernetes 集群之上，如上图所示。

• KubeDNS

在 Kubernetes 集群中调度运行提供 DNS 服务的 Pod，同一集群中的其他 pod 可使用此 DNS 服务解决主机名。Kubernetes 从 1.11 版本开始默认使用 CoreDNS 项目为集群提供服务注册和服务发现的动态名称解析服务，之前的版本中用到的是 kube-dns 项目，而 SKyDNS 则是更早一代的项目。

• Kubernetes Dashboard

Kubernetes 集群的全部功能都要基于 Web 的 UI，来管理集群中应用甚至是集群自身。

• Heapster

容器和节点的性能监控与分析系统，它收集并解析多种指标数据，如资源利用率、生命周期事件等。新版本的 Kubernetes 中，其功能会逐渐由 Prometheus 结合其他组件所取代。

• Ingress Controller

Service 是一种工作于传输层的负载均衡器，而 Ingress 是在应用层实现的 HTTP(s)负载均衡机制。不过，Ingress 资源自身不能进行 「流量穿透」，它仅是一组路由规则的集合，这些规则需要通过 Ingress 控制器 （Ingress Controller） 发挥作用。目前，此类的可用项目有 Nginx、Traefik、Envoy 及 HAProxy 等。

---

参考

• https://www.cnblogs.com/yanjieli/p/11792737.html
• https://kubernetes.io/docs/tutorials/kubernetes-basics/