深入理解Kubernetes内部组件

### 深入理解Kubernetes内部组件与机制 #### 1. 组件运行方式 Kubernetes的控制平面组件（Control Plane components），像etcd、API服务器、调度器（Scheduler）、控制器管理器（Controller Manager）等，以及kube - proxy，既可以直接部署在系统上，也能以Pod的形式运行。而Kubelet是唯一始终作为常规系统组件运行的组件，它负责将其他组件以Pod的形式运行。 在使用kubeadm创建的集群中，控制平面组件在主节点（master）上以Pod的形式运行。以下是查看kube - system命名空间中Pod的命令及结果： ```bash $ kubectl get po -o custom-columns=POD:metadata.name,NODE:spec.nodeName --sort-by spec.nodeName -n kube-system POD NODE kube-controller-manager-master master kube-dns-2334855451-37d9k master etcd-master master kube-apiserver-master master kube-scheduler-master master kube-flannel-ds-tgj9k node1 kube-proxy-ny3xm node1 kube-flannel-ds-0eek8 node2 kube-proxy-sp362 node2 kube-flannel-ds-r5yf4 node3 kube-proxy-og9ac node3 ``` 从上述列表可以看出，所有控制平面组件都在主节点上以Pod形式运行。同时，有三个工作节点（worker nodes），每个工作节点运行一个kube - proxy和一个Flannel Pod，Flannel为Pod提供覆盖网络。 使用`kubectl`时，可以通过`-o custom - columns`选项显示自定义列，并使用`--sort - by`对资源列表进行排序。 #### 2. Kubernetes对etcd的使用 Kubernetes使用etcd来持久存储创建的所有对象，如Pod、ReplicationControllers、Services、Secrets等，以确保在API服务器重启或故障时，这些对象的清单信息不会丢失。etcd是一个快速、分布式且一致的键值存储系统。由于它是分布式的，可以运行多个etcd实例来提供高可用性和更好的性能。 只有Kubernetes API服务器直接与etcd通信，其他组件通过API服务器间接读写etcd中的数据。这样做带来了一些好处，比如更强大的乐观锁系统和数据验证，并且将实际存储机制从其他组件中抽象出来，便于未来替换存储系统。需要强调的是，etcd是Kubernetes存储集群状态和元数据的唯一位置。 ##### 2.1 资源在etcd中的存储方式 Kubernetes可以使用etcd版本2或版本3，目前推荐使用版本3，因为其性能有所提升。etcd v2在分层键空间中存储键，类似于文件系统中的文件。每个键要么是包含其他键的目录，要么是带有对应值的常规键。etcd v3不支持目录，但由于键的格式保持不变（键可以包含斜杠），仍然可以将其视为分组到目录中。 Kubernetes将所有数据存储在etcd的`/registry`下，以下是`/registry`下存储的一些顶级键： ```bash $ etcdctl ls /registry /registry/configmaps /registry/daemonsets /registry/deployments /registry/events /registry/namespaces /registry/pods ... ``` 这些键对应着之前学习过的资源类型。 如果使用etcd API v3，不能使用`ls`命令查看目录内容，可以使用`etcdctl get /registry --prefix=true`列出以给定前缀开头的所有键。 以下是`/registry/pods`目录的内容： ```bash $ etcdctl ls /registry/pods /registry/pods/default /registry/pods/kube-system ``` 这两个条目分别对应默认和kube - system命名空间，说明Pod是按命名空间存储的。 以下是`/registry/pods/default`目录中的条目： ```bash $ etcdctl ls /registry/pods/default /registry/pods/default/kubia-159041347-xk0vc /registry/pods/default/kubia-159041347-wt6ga /registry/pods/default/kubia-159041347-hp2o5 ``` 每个条目对应一个单独的Pod，它们不是目录，而是键值对。以下是其中一个条目的存储内容： ```bash $ etcdctl get /registry/pods/default/kubia-159041347-wt6ga {"kind":"Pod","apiVersion":"v1","metadata":{"name":"kubia-159041347-wt6ga", "generateName":"kubia-159041347-","namespace":"default","selfLink":... ``` 可以看出，API服务器将资源的完整JSON表示存储在etcd中。由于etcd的分层键空间，可以将所有存储的资源视为文件系统中的JSON文件。 需要注意的是，在Kubernetes 1.7版本之前，Secret资源的JSON清单也是以明文形式存储的，如果有人直接访问etcd，就能获取所有的Secret信息。从1.7版本开始，Secrets被加密存储，更加安全。 ##### 2.2 乐观并发控制 乐观并发控制（有时也称为乐观锁）是一种方法，数据包含一个版本号，而不是锁定数据并阻止在锁定期间对其进行读取或更新。每次更新数据时，版本号会增加。当更新数据时，会检查版本号是否在客户端读取数据和提交更新之间增加。如果增加了，更新将被拒绝，客户端必须重新读取新数据并再次尝试更新。 所有Kubernetes资源都包含一个`metadata.resourceVersion`字段，客户端在更新对象时需要将该字段传递回API服务器。如果版本与etcd中存储的版本不匹配，API服务器将拒绝更新。 ##### 2.3 确保存储对象的一致性和有效性 与Kubernetes所基于的Google的Borg和Omega系统不同，Omega的多个控制平面组件直接访问存储系统，所有这些组件需要确保都遵循相同的乐观锁机制来正确处理冲突。而Kubernetes要求其他控制平面组件通过API服务器进行操作，这样集群状态的更新始终是一致的，因为乐观锁机制只在一个地方实现，减少了出错的可能性。API服务器还确保写入存储的数据始终有效，并且只有经过授权的客户端才能对数据进行更改。 ##### 2.4 集群化etc