标签：容器插件 Kubernetes kubernetes 详解集群组件 Pod 节点

Kubernetes是什么？

**Kubernetes 集群（Kubernetes Cluster）是一个由多个节点组成的系统，用于自动化部署、管理、扩展和操作容器化应用程序。Kubernetes 是一种开源的容器编排平台，它通过集群的形式来管理容器，使得应用的运行、管理和扩展变得更加高效和自动化。

基础概念与组件

docker

docker是容器引擎之一，提供 runtime 来运行容器
是kubernetes的 CRI 接口连接的对象之一

kubernetes

是容器集群管理系统的标准工具（容器编排）
可以实现容器集群的自动化部署、自动扩缩容、维护等功能
Master将所有Node节点的资源整合成一个资源池，提供接口给用户，用户只需要向 k8s 提供需求即可
当用户在集群上部署应用时，Master使用调度算法将其自动分配给某个最合适的Node，用户无需关心细节

kubernetes分层架构

从上自下依次是：

云原生生态系统：在接口层之上的庞大容器集群管理调度的生态系统，可以划分为两个范畴
- K8s外部：日志、监控、配置管理、CI/CD、Workflow、FaaS、OTS应用、ChatOps、GitOps、SecOps等
- K8s内部：CRI、CNI、CSI、镜像仓库、Cloud Provider、集群自身的配置和管理等
接口层：kubectl命令行工具、客户端SDK以及集群联邦
管理层：系统度量（如基础设施、容器和网络的度量），自动化（如自动扩展、动态Provision等）以及策略管理（RBAC、Quota、PSP、NetworkPolicy等）、Service Mesh（部分位于管理层）
应用层：部署（无状态应用、有状态应用、批处理任务、集群应用等）和路由（服务发现、DNS解析等）、Service Mesh（部分位于应用层）
核心层：Kubernetes最核心的功能，对外提供API构建高层的应用，对内提供插件式应用执行环境

API

Application Programming Interface（应用程序接口）
操作系统OS是用户与计算机硬件系统之间的接口。。。OS提供两类接口，其中之一就是API
该接口是为程序员在编程时使用的，系统和应用程序通过这个接口，可在执行中访问系统中的资源和取得 OS 的服务，它也是程序能取得操作系统服务的唯一途径

软件测试版本

Alpha 指的是内测，即现在说的 CB，即开发团队内部测试的版本或者有限用户的体验测试版本
Beta 指的是公测，即针对所有用户公开的测试版本
而做过一些修改，成为正式发布的候选版本时（现在叫做 RC - Release Candidate），叫做 Gamma
稳定版 stable

Kubernetes 集群的基本概念

节点 (Node)：
- Kubernetes 集群由多个节点组成。节点可以是物理服务器或虚拟机，每个节点在集群中充当工作负载的运行环境。
- 控制平面节点（Control Plane Node）：这些节点负责管理整个集群的状态和操作，运行 Kubernetes 的核心组件。
- 工作节点（Worker Node）：这些节点用于实际运行容器化的应用程序和服务。
控制平面 (Control Plane)：
- 控制平面管理集群的所有活动，负责调度、管理和控制集群内的应用程序。控制平面通常包括以下组件：
  - kube-apiserver：提供 API 接口，管理集群的所有操作。
  - etcd：存储集群的所有数据，包括配置、状态信息等。
  - kube-scheduler：负责调度 Pod 到合适的工作节点上。
  - kube-controller-manager：管理控制器，维持集群的期望状态。
Pod：
- Pod 是 Kubernetes 中最小的部署单元，通常包含一个或多个容器。Pod 内的容器共享同一个网络命名空间和存储卷。
- Pod 可以被调度到任何工作节点上运行，是 Kubernetes 中管理应用的基础单位。
服务 (Service)：
- Kubernetes 中的服务是一个抽象层，用于定义一组逻辑上的 Pod，并提供稳定的网络访问。
- 即使 Pod 动态变化，服务仍然可以通过单一 IP 地址或 DNS 名称访问这些 Pod。
命名空间 (Namespace)：
- 命名空间是 Kubernetes 中的一种隔离机制，用于在同一个集群内隔离不同的资源组。它允许多个团队或项目共享同一个集群，而不相互干扰。
部署 (Deployment)：
- 部署是 Kubernetes 中用于声明应用期望状态的控制器。通过部署，你可以定义应用的副本数、镜像版本等，并由 Kubernetes 自动管理。
持久化存储 (Persistent Storage)：
- Kubernetes 提供持久化存储机制，通过 PersistentVolume 和 PersistentVolumeClaim 来管理和使用持久化存储，确保数据在 Pod 重启或迁移后仍然存在。

Kubernetes 集群的特点

自动化管理：Kubernetes 能够自动调度和管理应用的运行，确保集群内的资源得到最优利用。
高可用性：通过自动修复、负载均衡和滚动更新等功能，Kubernetes 能够保持应用的高可用性。
扩展性：Kubernetes 提供了自动扩展功能，可以根据负载自动扩展或收缩应用实例。
灵活性：支持多种容器运行时（如 Docker、containerd）和多种云平台，使得 Kubernetes 能够适应各种不同的部署环境。

总结

Kubernetes 集群是一个复杂而强大的系统，用于管理和编排容器化应用程序。它通过控制平面和工作节点的协作，实现了应用的自动化部署、管理和扩展，帮助开发者和运维工程师更高效地管理容器化的应用和服务。**

Kubernetes集群的节点类型

Kubernetes集群由Master和Worker两类节点组成

Master：控制节点

是整个kubernetes集群的网关与中枢
以最优方式实现负载均衡
是各部分的核心联络点
单个Master即可实现自身的所有功能（但实际配置多台实现负载均衡和高可用）

Worker：工作节点

是kubernetes集群的工作节点
接收Master节点的指令，据此创建或销毁Pod
通过调整网络规则来实现合理地进行路由和转发流量
生产环境中Node节点数量众多

基本工作原理：

Master将所有Node节点的资源整合成一个资源池，提供接口给用户，用户只需要向 k8s 提供需求即可
当用户在集群上部署应用时，Master使用调度算法将其自动分配给某个最合适的Node，用户无需关心细节

运行逻辑

Kubernetes将所有工作节点的资源集结在一起形成一台更加强大的“服务器”
计算和存储接口通过Master之上的API Server暴露
客户端通过API提交应用程序的运行请求，而后由Master通过调度算法将其自动指派至某特定的工作节点以Pod对象的形式运行
Master会自动处理因工作节点的添加、故障或移除等变动对Pod的影响

资源抽象

Pod

是一个标准的资源类型（最基本的）
是在 Kubernetes 集群的最小调度单元
封装一个或多个容器
一个 Pod 中的所有容器共享NET namespace和存储资源
- 内部容器可通过lo直接通信
- 但彼此又在MNT/USER/PID等namespace上保持隔离
通常情况下，为了使Pod尽可能小，应该只包含一个主容器（业务），以及必要的辅助容器

Label

是将资源进行分类的标识符
本质上是键值对
标签只对用户有意义，与集群本身并无太大联系（便于管理）
标签能在创建对象的同时附加上去，创建后可随时添加或修改
一个对象能有多个标签、一个标签能附加给多个对象

Selector

根据标签来过滤符合条件的资源对象
用户使用标签将资源对象进行分类，使用标签选择器挑选出他们

Controller

用户不会直接管理部署Pod，而是借助各种Pod控制器完成
控制器有多种，其中用于工作负载的控制器用于管理Pod生命周期
- 比如Deployment负责确保指定的Pod的副本数量维持在指定值，否则多退少补
用户只需要声明应用的期望状态，控制器就会以此为目标进行自动管理

Service

Pod是动态消亡的对象，为了客户端能以固定入口访问容器，于是有了Service
本质上是四层代理服务（由kube-proxy生成的iptables或ipvs规则）
每个节点的kube-proxy都会将其所在节点上的每个Service的定义转换为ipvs或iptables规则！！！！！！！
通过Selector选定一组Pod，并为这组Pod定义一个统一的固定访问入口（如：ClusterIP）
若集群存在DNS附件，在Service创建之时会为其自动配置一个DNS_name，以便客户端进行服务发现
所有到达Service的请求将会负载均衡调度到后端各个Pod之上（选定的那一组Pod范围内）
可引入外部流量进入集群
- 同一Pod内部容器之间可直接通信
- Pod之间或Pod与Service之间使用内部专用地址通信
- 若需要开放指定的Pod给外部用户访问，就需要一个进入集群的通道，Service是实现方式之一

服务发现
'定义：针对客户端访问的服务，找到对应的的后端服务实例
'在K8s集群中，客户端需要访问的服务就是 Service对象
每个 Service 会对应一个集群内部的有效的虚拟IP，集群内部通过虚拟IP 访问一个确定的服务。# 负载均衡
'集群中微服务的负载均衡是由 Kube-proxy 实现的
Kube-proxy 是一个分布式代理服务器，集群上'每个【工作节点】都有一个Kube-proxy
需要访问服务的节点越多，提供负载均衡能力的 Kube-proxy 就越多，高可用节点也随之增多

Volume

是独立于容器文件系统之外的存储空间，常用于扩展容器的存储空间并实现持久存储
kubernetes集群的存储卷分为：临时卷、本地卷、网络卷
- 临时卷、本地卷位于本节点，若调度到其他节点则无法访问（因此常用于缓存）
- 需要持久化的数据放置于持久卷(persisent volume)之上

Name

是kubernetes集群中资源对象的标识符
作用域为一个namespace之内（一个namespace之内资源不能重名）
namespace用于资源隔离，形成逻辑分组
创建资源对象(如Pod、Service)时，若不指定namespace，则默认属于default namespace

注：Pod、Service都是namespace级别的资源对象！也存在其他级别的资源！！！

Annotation

是除标签之外，另一种附加在对象之上的键值对（比标签的容量更大）
常用于将各种非标识型元数据(metadata)附加给对象
不能用于标识或选择对象！！！主要是为了方便用户或工具来查找对象

Ingress

同一Pod内部容器之间可直接通信
Pod之间或Pod与Service之间使用内部专用地址通信
除了Service，Ingress也是引入外部流量的方式之一！！！

Kubernetes集群架构

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

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

注：

apiserver组件运行时的程序文件名为 kube-apiserver，其他类似
Master组件提供集群的管理控制中心
Master组件可以在集群中任何节点上运行。但是为了简单起见，通常在一台VM/机器上启动所有Master组件，并且不会在此VM/机器上运行用户容器
若整个集群中只有一个master节点，称之为单控制平面节点，学习阶段够用，但实际生产中必须设为高可用

核心组件

Master（控制节点）
apiserver # 各组件交互中心
scheduler # 调度。为Pod分配合适的节点
controller-manager # 控制中心。终极目标：维持spec期望状态
ETCD # 强一致的分布式K/V数据库。实现集群信息的持久化（自身已实现高可用）# Node（工作节点）
kubelet # 与容器引擎进行交互，管理Pod的生命周期
kube-proxy # 解决网络问题。将service转化为 iptables/ipvs 规则
Container engine # 容器引擎

Master组件

各个Master组件组成了一个完整的集群控制平面

API-Server

是所有组件相互通信的核心，是整个集群的网关
是唯一能与ETCD通信的组件，将集群数据持久存储于ETCD之中
任何的资源请求/调用操作都是通过apiserver提供的接口进行的，所有其他组件通过它进行交互
是所有Service规则的保存位置
apiserver的高可用，由前端的负载均衡服务器实现（通过健康监测功能实现）
负载均衡器自身的高可用，由keepalived设置VIP来实现
apiserver与Etcd基于https通信，状态信息都保存在后者，因此apiserver本身实现了无状态，因此设计冗余的时候不必设置过多，两三台已经足够（与实际业务规模相关）

Scheduler

集群的调度器
监控API-Server所有可用资源，为Pod调度最佳Node
API-Server确认Pod对象的创建请求之后，接下来便需要Scheduler进行调度选择Node创建Pod

注：kubernetes也支持用户自定义调度

Controller-manager

是许许多多的Controller的集合
是整个集群的司令部（决策中心），是集群内部的管理控制中心（实际上真正起作用的控制中心）
通过control loop确保集群的实际状态不断逼近期望状态（维持副本的期望数量）
当某个Node意外宕机时，它会及时发现并执行自动化修复流程，确保集群始终处于预期的工作状态
逻辑上，每个控制器是一个单独的进程；但为了降低复杂性，它们都被编译成单个二进制文件
这些控制器包括：
- 节点（Node）控制器
- 副本（Replication）控制器：负责维护系统中每个副本中的pod。
- 端点（Endpoints）控制器：填充Endpoints对象（即连接Services＆Pods）。
- Service Account和Token控制器：为新的Namespace创建默认帐户访问API Token-

ETCD

使用raft一致性算法实现，是一个强一致性的分布式K/V存储系统（注册中心）
是Kubernetes默认使用的key-value数据存储系统
用于保存集群所有的网络配置和对象的状态信息（共享配置和服务发现）
应该设置多个节点实现冗余，同时考虑脑裂问题，一般设置为3或5个
支持分布式集群功能，在生产环境使用时需要为 etcd数据提供定期备份机制
安装的时候指定的 Etcd 数据的存储路径是/var/lib/etcd，一定要对该目录做好备份！！！

整个kubernetes系统中一共有两个服务需要用到etcd用来协同和存储配置：

网络插件flannel、对于其它网络插件也需要用到 etcd存储网络的配置信息
kubernetes本身，包括各种对象的状态和元信息配置

Worker组件

Worker为运行容器提供各种依赖环境，并接受Master的管理

kubelet

是每个Node的核心代理程序，它会监视已分配给节点的pod，是运行在工作节点上的守护进程
在API-Server上注册当前节点的工作节点，定期向Master汇报节点资源使用情况
通过cAdvisor监控API-Server中Service的变化间接获得来自于scheduler的指令，然后调用容器引擎进行相关操作来维持目标状态
能管理存储卷！！！！

kube-proxy

是一个为了确保分散运行在各个节点上的Pod能够被正常调度的守护进程
每个节点的kube-proxy都会把整个集群的每个Service转换为自己的ipvs或iptables规则，从而捕获访问当前Service的ClusterIP的流量，并转发至正确的后端Pod
通过在主机上维护网络规则并执行连接转发来实现Kubernetes服务抽象

注：Kubernetes 网络代理运行在 Node 上，它反映了 Node 上 Kubernetes API 中定义的服务，并可以通过一组后端进行简单的 TCP、UDP 流转发或循环模式（round robin）的 TCP、UDP 转发，用户必须使用apiserver API创建一个服务来配置代理，其实就是kube-proxy通过在主机上维护网络规则并执行连接转发来实现 Kubernetes服务访问

Container engine

容器引擎，提供runtime环境以下载镜像并运行容器
kubelet以插件的方式载入配置的容器环境

核心附件

Master组件、Node组件，再加上一些核心附件，才能构成完整的集群

K8s 必备附件

Cluster DNS：集群DNS服务器，负责服务注册、发现和名称解析，所有Pod、Node相互之间通过主机名联系,当下的实现是CoreDNS
Network Plugin：网络插件，经由CNI接口，负责为Pod提供专用的通信网络，有多种实现
- CoreOS Flannel
- ProjectCalico
Ingress controller ：入站流量控制器，负责为Ingress资源提供具体的实现，实现http/https协议的七层路由和流量调度，有多种实现，例如
- Ingress-Nginx
- Contour
Kubernetes Dashboard/Kuboard/Rainbond：基于Web的UI,提供Web管理界面
Prometheus：指标监控系统，由此可实现故障发现与处理
Metrics Server：Node和Pod等相关组件的核心指标数据收集器，它接受实时查询，但不存储指标数据
OpenELB：适用于非云端部署的Kubernetes环境的负载均衡器，可利用BGP和ECMP协议达到性能最优和高可用性
日志收集与分析
- ELK（ Elasticsearch Logstash Kibana ）或 EFK（Elasticsearch Filebeat Kibana）
- LG（Loki Grafana）

# Logstash是基于Java编译器的Ruby语言开发，占用内存很大
# 而Filebeat相同情况下，内存占用可能只需要前者的千分之一！# Loki是仿照prometheus构建的工具
# Elasticsearch由Java开发（非云原生），而Loki是标准云原生工具

kubeDNS

集群中提供DNS服务的Pod。。此Pod为其他所有Pod解决DNS解析问题
服务注册和服务发现的总线：统称为 KubeDNS
kubeDNS的实现方案已经发展到第三代，产品名为CoreDNS
默认使用 CoreDNS 为集群提供服务注册和服务发现的动态名称解析服务
- 由于Pod到service的通信是直接访问service的name，因此需要CoreDNS进行解析
- CoreDNS监听API-Server中的每一个Service的定义，将其动态解析为自己的记录（A、PTR、SRV）

Dashboard

集群的全部功能都要使用基于Web的 UI 来管理内部应用甚至是集群自身

Prometheus

是容器和节点的性能监控与分析系统
收集并解析集群的多种指标数据

Ingress Controller

Ingress是在应用层实现的http(s) 负载均衡机制
Ingress本质是一组路由规则的集合，需要由Ingress Controller发挥作用
可用的实现方式：nginx、Envoy、HAprox...

kubernetes 核心组件详解