在整个 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 文件。