kubernetes基础理论
kubernetes基础理论
HappyLadySauceKubernetes概念
Kubernetes（K8S）是一个开源的容器编排平台，用于自动化部署、扩展和管理容器化应用程序。它采用主从模型（Master-Slave架构），其中物理主机分为Master和Node两种角色。
主节点（Master）
Master节点是Kubernetes集群的控制中心，负责集群的调度、管理和运维。在高可用性配置中，建议至少部署三个Master节点。Master节点通过与Node节点的通信来维持整个集群的健康状态，并将资源状态信息存储在etcd中。如果Master节点不可用，将无法管理集群资源。
Master节点上部署的关键组件包括：
- apiserver：提供资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制。
- scheduler：负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上。
- controller-manager：负责维护集群的状态，比如故障检测、自动扩展、滚动更新等。
- etcd：保存了整个集群的状态。
从节点（Node）
Node节点，也称为Worker节点，是集群中执行工作负载的节点。Node节点上的kubelet会将状态信息汇报给Master节点的apiserver，并存储在etcd中。如果某个Node节点宕机，其上的工作负载会被自动转移到其他Node节点。
Node节点上部署的关键组件包括：
- kubelet：负责维护容器的生命周期，同时也负责Volume（CSI）和网络（CNI）的管理。
- kube-proxy：负责为Service提供cluster内部的服务发现和负载均衡。
- 容器引擎：如Docker或containerd，负责镜像管理以及Pod和容器的真正运行（CRI）。
Kubernetes的核心概念
- 组件：实际存在的软件，如apiserver、scheduler、controller-manager、kubelet、kube-proxy等。
- 资源：组件创建的逻辑单位，如namespace、pod、deployment、configmap、statefulset等。
名称空间（Namespace）
名称空间技术用于隔离资源，如pid、ipc、uts、mount、network、user等。在Kubernetes中，名称空间用于将一系列资源隔离到一起，便于统一管理配置，如资源配额和访问控制。
- 资源配额：限定一个名称空间内可用的总资源量。
- Limit Range：限定当前名称空间内每个pod或容器的最大资源使用量。
Pod
Pod是Kubernetes的最小部署单元，包含一个或多个容器。Pod是组织容器的单位，Pod内的容器共享网络和存储卷，便于本地通信和共享存储。
Pause容器
Pause容器用于初始化Pod的网络环境，因此每个Pod至少包含两个容器。Kubernetes不使用容器引擎自带的网络，而是使用pause容器提供网络服务，并共享网络给其他容器服务。
网络模型
Kubernetes网络模型确保了节点、Pod、服务以及外部流量之间的通信。Kubernetes自动调度网络流量，确保它们能正确到达各个节点上的资源。Pod上的网络服务通过Kubernetes服务对外提供，提供单一的IP和DNS名称，支持服务扩展，并在必要时允许外部访问。
Kubernetes核心组件
Node节点上部署的组件
1. 容器引擎
负责具体后端容器运行时的软件，kubernetes支持多个容器运行环境：Docker、Containerd、CRI-O以及任何实现Kubernetes CRI（容器运行环境接口）。
2. kubelet
kubelet有以下功能：
- Kubelet是Master节点安插在Node节点上的“眼线”，它会定时向API Server汇报自己Node节点上运行的服务的状态。
- kubelet会接收Master的指示来维护当前工作节点的Pod达到预期状态（比如运行什么容器、运行的副本数量、网络或者存储、容器的存活和健康检测等容器整个生命周期都归kubelet管）。
- 入手容器的创建：kubelet是通过cri（container runtime interface）接口来调用容器引擎实现的，kubelet先创建一个Pause网络容器，再去创建业务容器。
3.kube-proxy组件与service组件
运行有kubelet的节点都会运行kube-proxy组件，kube-proxy不负责pod的网络构建，kube-proxy负责管理service资源以实现pod的负载均衡代理（智能负载均衡、4层）。
为了实现应用的高可用：
传统情况，我们会将应用部署为多个副本，然后用一个负载均衡如 nginx 来代理这些副本，并且要监测副本的故障，故障副本要从代理中剔除。
1 | |------------ 相同应用副本1 |
而在k8s中，内置了service资源，你只需要按需创建service来代理你的pod即可，service与nginx代理的作用一样。
1 | |------------ 相同应用Pod副本1 |
service与pod的动态关联（挂掉pod自动剔除对其的代理，新pod自动添加对其的代理，这都是基于pod标签来实现的）
Master节点上部署的组件
1. etcd分布式数据库
Etcd是用go语言开发的一个分布式的K/V存储系统，etcd相当于整个k8s集群的记事本/存储中心，k8s集群的所有状态都记录在etcd数据库集群中。
ETCD核心使用了RAFT分布式一致性算法，因此通常部署奇数个
1 | 了解raft协议： |
补充：etcd集群的性能决定了k8s集群的规模。
2. apiserver
K8s所有的状态信息都存放在etcd集群中，而etcd只能被apiserver操作，所以K8s所有其他组件运行时都只能去访问apiserver才能间接地访问到etcd数据库，因此apiserver是整个K8S集群入口，是k8s所有模块之间相互通信和数据交互的中心，相当于整个k8s的大脑/大总管/中央枢纽
3. kube-scheduler
实际环境中会有多台机器用于跑容器，如何从中选取最合适的那一台，这就用到了k8s的组件：kube-scheduler scheduler会经历预选（选择出符合条件的）与优先（选出资源最优的）两个阶段来选出合适的一个node节点，然后该node节点上的kubelet会收到请求来调用容器引擎创建pod
创建pod时，scheduler组件会经过两个阶段来完成物理节点的挑选
1、预选（选出符合条件的）
2、优选（选出资源最优的）
4. kube-controller-manager
在K8S集群中，几乎每种特定资源都有特定的Controller控制器负责维护管理。
我们以POD这种资源为例，POD启动后，K8s需要对齐进行自动化管理，例如故障监控与自愈，这都需要有专门的程序负责维护，这个程序就是K8s的控制器，控制器有内置的，后续你也可以自定义，内置的控制种类有deployment、statefulset、daemonset、cronjob等，不同的控制器的有不同的特性。
其实不仅仅是Pod资源，几乎每一种k8s的资源都有对应的控制器来负责管理维护使其使其始终处于预期状态，完成自动化管理工作。
控制器的管理器controller-manager
为了把诸多种类的Controller聚合起来进行统一管理，抽取冗余实现降低Controller的实现复杂度，K8s中诞生了一个controller-manager的组件，即控制器管理器，它是K8S集群里所有资源对象的自动化控制中心，是K8S集群中处理常规任务的后台线程。
Controller Manager的负责把所有的Controller聚合起来，一方面可以提供基础设施降低Controller的实现复杂度，另外一方面就是负责启动和维持Controller的正常运行，监听api-server的事件，然后对不同的Controllers发号施令。
controller-manager负责监视着每一个控制器（控制器通过API Server监控整个集群的状态），如果某个控制器无法工作，那么controller-manager会及时发现并执行自动化修复流程来确保控制器的健康，使得集群处于预期的工作状态。由于Master有多个，所以controller-manager具有冗余性。
