etcd：Kubernetes集群大脑

背景
Etcd是Kubernetes的一个关键组件，因为它存储集群的整个状态：配置、规范和正在运行的工作负载的状态。在这篇文章中，我们将揭开它的神秘面纱，以了解etcd如何存储所有这些信息。

官网地址：
https://etcd.io
在kubernets世界中，etcd用作服务发现的后端，并存储集群的状态及其配置。
Etcd作为一个集群部署，几个节点的通信由Raft算法处理。在生产环境中，群集包含奇数个节点，并且至少需要三个节点。在http://thescretlivesofdata.com/中，您可以找到一个很好的动画来解释这个算法是如何运行的，它演示了集群生命周期的几个阶段，其中包括：

领导人选举；

日志复制

Raft algorithm explained in thesecretlivesofdata.com

原理与实践
ETCD in kubernetes

Etcd部署在集群内

Etcd 部署在集群外面

pod创建过程中各组件交互， 主要是API server 与etcd
获取Etcd的键值对

$ ADVERTISE_URL="https://134.209.178.162:2379"
$ kubectl exec etcd-node-01 -n kube-system -- sh -c \
"ETCDCTL_API=3 etcdctl \
--endpoints $ADVERTISE_URL \
--cacert /etc/kubernetes/pki/etcd/ca.crt \
--key /etc/kubernetes/pki/etcd/server.key \
--cert /etc/kubernetes/pki/etcd/server.crt \
get \"\" --prefix=true -w json" > etcd-kv.json

对该文件的快速检查将显示密钥列表及其相应的值，这两个值都以base64编码（此处仅显示文件的提取）。

让我们先用纯文本获取所有键，看看它们是什么样子的

for k in $(cat etcd-kv.json | jq '.kvs[].key' | cut -d '"' -f2); do echo $k | base64 --decode; echo; done

/registry/apiregistration.k8s.io/apiservices/v1.
/registry/apiregistration.k8s.io/apiservices/v1.apps
/registry/apiregistration.k8s.io/apiservices/v1.authentication.k8s.io
/registry/apiregistration.k8s.io/apiservices/v1.authorization.k8s.io
/registry/apiregistration.k8s.io/apiservices/v1.autoscaling
/registry/apiregistration.k8s.io/apiservices/v1.batch
/registry/apiregistration.k8s.io/apiservices/v1.coordination.k8s.io
/registry/apiregistration.k8s.io/apiservices/v1.networking.k8s.io
/registry/apiregistration.k8s.io/apiservices/v1.rbac.authorization.k8s.io
/registry/apiregistration.k8s.io/apiservices/v1.scheduling.k8s.io
/registry/apiregistration.k8s.io/apiservices/v1.storage.k8s.io
/registry/apiregistration.k8s.io/apiservices/v1beta1.admissionregistration.k8s.io
/registry/apiregistration.k8s.io/apiservices/v1beta1.apiextensions.k8s.io
/registry/apiregistration.k8s.io/apiservices/v1beta1.apps
/registry/apiregistration.k8s.io/apiservices/v1beta1.authentication.k8s.io
/registry/apiregistration.k8s.io/apiservices/v1beta1.authorization.k8s.io
/registry/apiregistration.k8s.io/apiservices/v1beta1.batch
/registry/apiregistration.k8s.io/apiservices/v1beta1.certificates.k8s.io
/registry/apiregistration.k8s.io/apiservices/v1beta1.coordination.k8s.io
/registry/apiregistration.k8s.io/apiservices/v1beta1.events.k8s.io
/registry/apiregistration.k8s.io/apiservices/v1beta1.extensions
/registry/apiregistration.k8s.io/apiservices/v1beta1.networking.k8s.io
/registry/apiregistration.k8s.io/apiservices/v1beta1.node.k8s.io
/registry/apiregistration.k8s.io/apiservices/v1beta1.policy

整理之后发现包含以下集群资源信息

Nodes 
Namespaces
ServiceAccounts
Roles and RoleBindings, ClusterRoles / ClusterRoleBindings
ConfigMaps
Secrets
Workloads: Deployments, DaemonSets, Pods, …
Cluster’s certificates
The resources within each apiVersion
The events that bring the cluster in the current state

选择其中一个键后，我们可以使用以下命令获取相关值：

$ kubectl exec etcd-node-01 -n kube-system —- sh -c \
"ETCDCTL_API=3 etcdctl \
--endpoints $ADVERTISE_URL \
--cacert /etc/kubernetes/pki/etcd/ca.crt \
--key /etc/kubernetes/pki/etcd/server.key \
--cert /etc/kubernetes/pki/etcd/server.crt \
get \"KEY\" -w json"

以这个key举例
/registry/deployments/kube-system/coredns:

如果我们解码与这个键相关联的值，返回的内容就不是很可读，因为有些字符不能被解释，但是当然，Kubernetes知道如何正确地处理它们

根据这个结果，我们可以推断这个密钥用于存储管理coredns pod的部署的规范和状态。

让我们创建一个Pod并检查集群的状态是如何修改的，以及添加了哪些新键。

$ cat <<EoF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: www
spec:
  containers:
  - name: nginx
    image: nginx:1.16-alpine
EoF

使用与前面相同的命令，我们获取所有密钥并将此列表保存在etcd-kv-after-nginx-pod.json中。快速比较两个密钥列表，一个是在创建集群之后检索的密钥（etcd kv.json），另一个是在部署了www Pod之后检索的密钥（etcdkv after nginx Pod.json），显示以下内容：

> /registry/events/default/www.15b9e3051648764f
> /registry/events/default/www.15b9e3056b8ce3f0
> /registry/events/default/www.15b9e306918312ea
> /registry/events/default/www.15b9e306a32beb6d
> /registry/events/default/www.15b9e306b5892b60
> /registry/pods/default/www

五个事件和一个pod，这是有道理的。让我们仔细看一看，并从解码与事件键相关联的值开始。按照时间顺序，我们可以看到它们与以下操作关联：

Successfully assigned default/www to node-02
Pulling image “nginx:1.16-alpine
Successfully pulled image “nginx:1.16-alpine
Created container nginx
Started ”Started container nginx

这些事件列在描述Pod的命令末尾：

kubectl describe pod www

最后一个键/registry/pods/default/www提供了与新创建的Pod相关的所有信息：
总结
本文的目的不是深入研究etcd，而是解释它包含什么以及信息是如何组织的。这样做我希望它看起来不像一个黑盒。