kubernetes（K8S）集群组件(一) ------ 简介

       在整个 Kubernetes 集群中，有多个主机   一个主机作为一个节点（ node），  一个节点中可以有一个或多个 pod，  一个pod中有多个或一个 docker,   一般在一个docker 中运行一个服务进程。

        遵循单一原则，一个容器只运行一个主进程。

        多个进程都部署在一个容器中，弊端很多。比如更新某个进程的镜像时，其他进程也会被迫重启，如果一个进程出问题导致容器挂了，所有进程都将无法访问。

https://www.cnblogs.com/lyf-linux/articles/17342345.html

kubernetes（K8S）集群组件简介

kubernetes集群概述

​ Kubernetes最初源于谷歌内部的Borg，Borg是谷歌内部的大规模集群管理系统，负责对谷歌内部很多核心服务的调度和管理,Borg的目的是让用户能够不必操心资源管理的问题，让他们专注于自己的核心业务，并且做到跨多个数据中心的资源利用率最大化

​ kubernetes是一个跨多主机的容器编排平台，它使用共享网络将多个主机构建成统一的集群。其中，一个或少量几个主机运行为Master节点，作为控制中心负责管理整个集群系统，余下的所有主机运行为Worker Node节点

​ kubernetes属于典型的C/S形式的二层架构，集群主要由Master组件、Node组件以及核心附件等组成。在程序级别，Master主要由API Server（kube-apiserver）、Controller-Manager（kube-controller-manager）和Scheduler（kube-scheduler）这3个组件以及用于集群状态存储的etcd存储服务组成，它们构成了集群的控制平面；而每个Node节点主要由kubelet、kube-proxy以及容器运行时（docker、containerd等）组成，它们承载运行各类应用容器。

​ K8S集群各组件架构如图：

Master组件

​ Master组件是集群的”脑力“输出者，它维护有K8S的所有对象记录，负责持续管理对象状态并响应集群中各种资源对象的管理操作，以及确保各资源对象的实际状态于所需状态相匹配，控制平面各组件主要包括如下：

kubernetes API Server

​ API Server是整个集群的网关接口，由kube-apiserver守护进程运行为服务，通过HTTP/HTTPS协议将RESTful API公开给用户，是发往集群的所有REST操作的接入点，用于接收、校验、以及响应所有REST请求，并将结果状态持久存储于集群状态存储系统（etcd）中。

​ API Server守护进程默认监听6443 端口，可通过启动参数 “-- secure-port”的值来修改默认值；默认监听IP为0.0.0.0及本机所有IP，可以通过启动参数“--bind-address”设置监听指定的内网IP ；该端口用于接收客户端、dashboard等外部HTTPS请求 ；实现基于策略的账户鉴权及准入 ；客户端通过API Server实现对kubernetes的API远程以实现对kubernetes内部资源的增删改查等管理任务的分发 。

​ API的版本：
​ 1）Alpha：预览版，可能包含bug或错误，后期版本会修复且不兼容之前的版本，不建议使用。
​ 2）Beta：测试版,如storage.k8s.io/v1beta1,该版本可能存在不稳定或者潜在的bug，不建议生产使用
​ 3）v1/v2/vX: 稳定版，如apps/v1，经过验证的stable版本，可以生产环境使用

kube-scheduler

​ K8S系统上的调度是指为API Server接收到的每一个pod创建请求，并在集群中为其匹配一个最佳工作节点。kube-scheduler是默认调度器程序，在匹配工作节点时的考量因素包括硬件、软件、策略约束、亲和力、反亲和力规范以及数据的局部性特征。

​ 通过调度算法为待调度Pod列表的每个Pod从可用Node列表中选择一个最适合的Node，并将信息写入etcd中 ；node节点上的kubelet通过API Server监听到kubernetes Scheduler产生的Pod绑定信息，然后获取对应的Pod清单，下载Image ，并启动容器 。

​ 调度过程分为两个阶段，第一阶段是预选期，第二阶段为优选实施期

​

​ 调度过程大致为：创建Pod --> Filter Nodes:过滤掉资源不足的节点 --> Rank Nodes:在剩余可用的节点中进行评分筛选 -->选中目的node节点

kube-controller-manager

​ 帮助文档：kube-controller-manager | Kubernetes

​ 控制管理器负责实现用户通过API Server提交的终态声明，它通过一系列操作步骤驱动API对象的当前状态逼近或等同于期望值。K8S提供了驱动Node、Pod、Server、Endpoint、ServiceAccount和Token等数十种类型API对象的控制器。逻辑上将，每个控制器都是一个独立的进程，但是为了降低复杂性，它们被编译进单个二进制程序文件kube-controller-manager，并以单个进程运行

​ controller-manager控制器每间隔5秒检查一次节点的状态 ，如果controller-manager控制器没有收到自节点的心跳，则将该node节点被标记为不可达 ；controller-manager将在标记为无法访问之前等待40秒 ，如果该node节点被标记为无法访问后5分钟还没有恢复，controller-manager会删除当前node节点的所有pod并在其它可用节点重建这些pod

​ 高可用集群中kube-controller-manager基于--leader-elect=true 启动参数实现多节点高可用，会自动选举leader，原理是有一把分布式锁，哪个节点先抢到锁谁就是 leader(基于hostname设置为锁的持有者)，leader需要定期更新自己持有的锁状态，如超时未更新则 会发新的leader选举

​ pod 高可用机制:

​ 1）node monitor period: 节点监视周期,5s

​ 2）node monitor grace period: 节点监视器宽限期,40s

​ 3）pod eviction timeout: pod驱逐超时时间,5m

etcd（集群状态存储）组件

​ K8S集群的所有状态信息都需要持久存储于存储系统etcd中。etcd是由CoreOS公司基于Raft协议开发的分布式键值存储，可用于服务发现、共享配置以及一致性保障。

​ etcd为其存储的数据提供了监听（watch）机制，用于监听和推送变更。API Server是K8S集群中唯一能与etcd通信的组件，它封装了这种监听机制，并借此和其它各组件高效协同。

​ 生产环境使用时需要为etcd数据提供定期备份机制。

Node组件

​ Node组件是集群的”体力“输出者，一个集群通常有多个Node以提供足够的承载力来运行容器化应用和其他工作负载，每个Node会定期向Master报告自身的状态，并接受Master管理。

kubelet

​ kubelet组件是K8S中最重要的组件之一，运行于每个Node（Worker）上的”节点代理“服务，负责接收并执行Master发来的指令，以及管理当前Node上的Pod对象等任务。

​ 它支持从API Server上以配置清单形式接收Pod资源定义，或者从本地指定目录中加载静态Pod配置清单，并通过容器运行时创建、启动和监视容器。

​ kubelet会持续监视当节点各Pod的健康状态，包括基于探针进行存活状态探测，并在任何Pod出现问题时将其重建为新实例。

​ 它内置了一个HTTP服务器，监听TCP的10248和10250端口：10248通过/heathz响应对kubelet程序自身监控状态检测；10250端口用于暴露kubelet API，以验证、接收并响应API Server的通信请求

kube-proxy

​ 官网地址：kube-proxy | Kubernetes

​ kube-proxy是需要运行于集群中每个节点之上的服务进程，它把API Server上的Service资源对象转换为当前节点上的iptables规则或（与）ipvs规则。这些规则能够将发往该Service对象ClusterIP的流量分发至它后端的Pod端节点上。

​ kube-proxy是K8S集群的核心网络组件，它本质上更像是Pod的代理和负载均衡，负责确保集群中Node、Service和Pod对象之间的有效通信。

​ IPVS 相对 IPtables 效率会更高一些，使用 IPVS 模式需要在运行 Kube-Proxy 的节点上安装 ipvsadm、ipset 工具包和加载 ip_vs 内核模块，当 Kube-Proxy 以 IPVS 代理模式启动时，Kube-Proxy 将验证节点上是否安装了 IPVS 模块，如果未安装，则 Kube-Proxy将回退到 IPtables 代理模式 。

​ 使用IPVS模式，Kube-Proxy会监视Kubernetes Service对象和Endpoints，调用宿主机内核Netlink接口以相应地创建IPVS规则并定期与Kubernetes Service对象 Endpoints对象同步IPVS规则，以确保IPVS状态与期望一致，访问服务时，流量将被重定向到其中一个后端 Pod,IPVS使用哈希表作为底层数据结构并在内核空间中工作，这意味着IPVS可以更快地重定向流量，并且在同步代理规则时具有更好的性能，此外，IPVS 为负载均衡算法提供了更多选项，例如：rr (轮询调度)、lc (最小连接数)、dh (目标哈希)、sh (源哈希)、sed (最短期望延迟)、nq(不排队调度)等。默认调度算法为rr 。

​ 配置使用IPVS及指定调度算法：

参考文档：kube-proxy 配置 (v1alpha1) | Kubernetes

# cat /var/lib/kube-proxy/kube-proxy-config.yaml  

kind: KubeProxyConfiguration
apiVersion: kubeproxy.config.k8s.io/v1alpha1
bindAddress: 172.31.7.111
clientConnection:
kubeconfig: "/etc/kubernetes/kube-proxy.kubeconfig"
clusterCIDR: "10.100.0.0/16"
conntrack:
maxPerCore: 32768
min: 131072
tcpCloseWaitTimeout: 1h0m0s
tcpEstablishedTimeout: 24h0m0s
healthzBindAddress: 172.31.7.111:10256
hostnameOverride: "172.31.7.111"
metricsBindAddress: 172.31.7.111:10249
mode: "ipvs" #指定使用ipvs及调度算法
ipvs:
scheduler: sh    

核心附件

​ 附件（add-ons）用于扩展K8S的基本功能，通常运行于K8S集群自身之上。根据重要性分为必要和可选两类

​ 必要插件：

​ 1）网络插件是必要附件，常用的网络插件有Flannel、Calico、Canal、Cilium、Weave Net等

​ 2）KubeDNS通常也是必要附件，用于实现应用程序名称解析和服务发现功能，1.11版本开始默认使用CoreDNS

​ 可选插件：

​ 1）Dashboard：基于web的用户接口，用于可视化K8S集群

​ 2）容器资源监控系统：监控系统是分布式应用的重要基础设施，K8S常用的指标监控附件包括：Metrics-Server、kube-state-metrics、Prometheus。

​ 3）集群日志系统：日志系统是构建可观测分布式应用的另一个关键性基础设施，用于向监控系统的历史时间补充更详细的信息。K8S集群常用的日志系统是Elasticsearch、Fluentd和Kibana（EFK）组合的整体解方案

​ 4）Ingress Controller： Ingress资源是kubernetes集群将外部HTTP/HTTPS流量引入到集群内部专用的资源类型，它仅用于控制流量的规则和配置的集合，其自身不能进行”流量穿透“，要通过Ingress控制器发挥作用。此类常用的项目有Nginx、Traefik、Envoy、Gloo、Haproxy等

kubectl

​ 官方文档：kubectl | Kubernetes

​ kubectl是一个通过命令行对kubernetes集群进行管理的客户端工具。

​ kubectl 在 $HOME/.kube 目录中查找一个名为 config 的配置文件。 你可以通过设置 KUBECONFIG 环境变量或设置 --kubeconfig参数来指定其它kubeconfig 文件。