01.Kubernetes 概述

Kubernetes 概述

Kubernetes 适用于所有编排语言，且解决更广泛的 MSA 的问题

Kubernetes 还支持配置环境、设置资源约束、RBAC、管理应用程序生命周期、启用自动扩展和自我修复等，自带反脆弱能力

由 Master 和 Worker 两类节点组成：

运行逻辑

Kubernetes 属于典型的 Server-Client 形式的二层架构

Master 主要由 API Server、Controller-Manager 和 Scheduler 三个组件，以及一个用于集群状态存储的 Etcd 存储服务组成，它们构成整个集群的控制平面
而每个 Node 节点则主要包含 Kubelet、Kube Proxy 及容器运行时（docker是最为常用的实现）三个组件，它们承载运行各类应用容器

Kubernetes 集群于每个 Worker 节点上的代理，相应程序为 kubelet
接收并执行 Master 发来的指令，管理由 Scheduler 绑定至当前节点上的 Pod 对象的容器
- 通过 API Server 接收 Pod 资源定义，或从节点本地目录中加载静态 Pod 配置
- 借助于兼容 CRI 的容器运行时管理和监控 Pod 相关的容器

运行于每个 Worker 节点上，专用于负责将 Service 资源的定义转为节点本地的实现
- iptables 模式：将 Service 资源的定义转为适配当前节点视角的 iptables 规则
- ipvs 模式：将 Service 资源的定义转为适配当前节点视角的 ipvs 和少量 iptables 规则
是打通 Pod 网络在 Service 网络的关键所在

负责扩展 Kubernetes 集群的功能的应用程序，通常以 Pod 形式托管运行于 Kubernetes 集群之上

必选插件

Network Plugin：网络插件，经由 CNI 接口，负责为 Pod 提供专用的通信网络，有多种实现
- CoreOS Flannel
- ProjectCalico
Cluster DNS：集群 DNS 服务器，负责服务注册、发现和名称解析，当下的实现是 CoreDNS

重要插件

Ingress Controller：Ingress 控制器，负责为 Ingress 资源提供具体的实现，实现 http/https 协议的七层路由和流量调度，有多种实现，例如 Ingress-Nginx、Contour 等
Metrics Server：Node 和 Pod 等相关组件的核心指标数据收集器，它接受实时查询，但不存储指标数据
Kubernetes Dashboard/Kuboard/Rainbond：基于 Web 的UI
Prometheus：指标监控系统
ELK/PLG：集中式日志系统
OpenELB：适用于非云端部署的 Kubernetes 环境的负载均衡器，可利用 BGP 和 ECMP 协议达到性能最优和高可用性

Kubernetes 本质上是“以应用为中心”的现代应用基础设施，Pod 是其运行应用及应用调度的最小逻辑单元

在设计上，仅应该将具有“超亲密”关系的应用分别以不同容器的形式运行于同一 Pod 内部

本质上是共享 Network、IPC 和 UTS 名称空间以及存储资源的容器集
- 可将其想象成一台物理机或虚拟机，各容器就是该主机上的进程
- 各容器共享网络协议栈、网络设备、路由、IP地址和端口等，但 Mount、PID和 USER 仍隔离
- 每个 Pod 上还可附加一个“存储卷（Volume）”作为该“主机”的外部存储，独立于 Pod 的生命周期，可由 Pod 内的各容器共享
模拟“不可变基础设施”，删除后可通过资源清单重建
- 具有动态性，可容忍误删除或主机故障等异常
- 存储卷可以确保数据能超越 Pod 的生命周期

Pod 具有动态性，其 IP 地址也会在基于配置清单重构后重新进行分配，因而需要服务发现机制的支撑

Kubernetes 使用 Service 资源和 DNS 服务（CoreDNS）进行服务发现

Service 能够为一组提供了相同服务的 Pod 提供负载均衡机制，其 IP 地址（Service IP，也称为 Cluster IP）即为客户端流量入口
一个 Service 对象存在于集群中的各节点之上，不会因个别节点故障而丢失，可为 Pod 提供固定的前端入口
Service 使用标签选择器（Label Selector）筛选并匹配 Pod 对象上的标签（Label），从而发现Pod
- 仅具有符合其标签选择器筛选条件的标签的 Pod 才可由 Service 对象作为后端端点使用