Kubernetes系列(1)——架构

半日闲 2020年12月02日 31次浏览

前言

Kubernetes来源于Google的Brog项目,并且一经发布,即引起了轩然大波,成为了事实上容器编排引擎的标准。
Kuberntes的总体架构图如下
image.png
可以看到Kubernetes基本上分为2部分,分别是Control Plane(控制平面)和Work Plane(工作平面)。
控制平面上主要有API server,Controller manager,etcd,Scheduler和Cloud controller manager(可选),其中Cloud controller manager现在还处于实现阶段。
工作平面上主要有kube-proxy,kubelet。
那么API server是如何通知客户端资源变更呢?
image.png
如上,所有的客户端都会监听API server,当用户提交了资源更新的时候,由API server更新该资源在etcd中的状态,当etcd修改成功后,API server随后通知所有监听者更新之后的资源信息,具体的更新操作交由后续的客户端完成
本系列中的kubernetes集群版本为v1.18.2 ,如下
image.png

控制平面

生产环境中,强烈建议控制平面上的API server和etcd配置高可用,否则一旦出现单点故障,集群直接崩溃

API server

Kubernetes API server 为 api 对象验证并配置数据,包括 pods、 services、 replicationcontrollers 和其它 api 对象。API Server 提供 REST 操作和到集群共享状态的前端,所有其他组件通过它进行交互。
API server提供2种访问方式,1是命令行,2是API的方式。

使用API的方式访问API server如下

export clientcert=$(grep client-cert ~/.kube/config |cut -d" " -f 6)
export clientkey=$(grep client-key-data ~/.kube/config |cut -d" " -f 6)
export certauth=$(grep certificate-authority-data ~/.kube/config |cut -d" " -f 6)
echo $clientcert | base64 -d > ./client.pem
echo $clientkey | base64 -d > ./client-key.pem
echo $certauth | base64 -d > ./ca.pem
kubectl config view |grep server
curl --cert ./client.pem --key ./client-key.pem --cacert ./ca.pem https://192.168.1.8:6443/api/v1/pods

可以直接使用以下命令

curl --cert /etc/kubernetes/ssl/admin.pem --key /etc/kubernetes/ssl/admin-key.pem --cacert /etc/kubernetes/ssl/ca.pem https://192.168.1.8:6443/api/v1/pods

因为/root/.kube/config文件中的证书其实就是Kubernetes创建集群时的admin的证书经过base64之后的结果
命令执行后,输出结果为json,如下
image.png**

Controller manager

该组件通过API server管理并且监控集群的各种资源,主要包括以下以下

  • 节点控制器(Node Controller): 负责在节点出现故障时进行通知和响应。
  • 副本控制器(Replication Controller): 负责为系统中的每个副本控制器对象维护正确数量的 Pod。
  • 端点控制器(Endpoints Controller): 填充端点(Endpoints)对象(即加入 Service 与 Pod)。
  • 服务帐户和令牌控制器(Service Account & Token Controllers): 为新的命名空间创建默认帐户和 API 访问令牌。

etcd

etcd 是兼具一致性和高可用性的键值数据库,用于保存集群中 所有的网络配置和对象的状态信息 
同样,etcd也可以用过命令行工具etcdctl进行控制,可前往github上下载该工具
执行命令如下

etcdctl get /registry/pods --prefix -w json|python -m json.tool > etcdctl.json
head -n 30 etcdctl.json

执行如下
image.png
Kubernetes存储在etcd中的数据全部处于/registry路径下,使用如下脚本可以遍历Kubernetes的元数据的key,如下

keys=`etcdctl get /registry --prefix -w json|python -m json.tool|grep key|cut -d ":" -f2|tr -d '"'|tr -d ","`
for x in $keys;do
  echo $x|base64 -d|sort
done

执行如下
image.png
本节etcdctl参考etcdctl操作

Scheduler

该组件监视那些新创建的未指定运行节点的 Pod,并选择节点让 Pod 在上面运行。
调度决策考虑的因素包括单个 Pod 和 Pod 集合的资源需求、硬件/软件/策略约束、亲和性和反亲和性规范、数据位置、工作负载间的干扰和最后时限。

工作平面

kube-proxy

该组件是集群中每个节点上运行的网络代理, 实现 Kubernetes Service 概念的一部分。
kube-proxy 维护节点上的网络规则。这些网络规则允许从集群内部或外部的网络会话与 Pod 进行网络通信。
如果操作系统提供了数据包过滤层并可用的话,kube-proxy 会通过它来实现网络规则。否则, kube-proxy 仅转发流量本身。

kubelet

一个在集群中每个节点上运行的代理。它保证容器都运行在 Pod 中。
kubelet 接收一组通过各类机制提供给它的 PodSpecs,确保这些 PodSpecs 中描述的容器处于运行状态且健康。kubelet 不会管理不是由 Kubernetes 创建的容器。