标签：ash Kubernete data 作用 初始 tar int sources pen
英文原文：A Closer Look at Etcd: The Brain of a Kubernetes Cluster
译文原文：[译]走进Kubernetes集群的大脑：Etcd
译者：野生程序元
Etcd是Kubernetes用于存储集群各种状态信息（配置信息，运行）一个很重要的组件，这篇文章，我们带领大家掀开Etcd的神秘面纱，理解他是如何存储这些各种各样的碎片信息的。
Etcd 是一个分布式的，依赖key-value存储的，最重要的分布式数据存储系统
-- etcd.io
在Kubernetes的世界里面，etcd是服务发现，集群状态存储以及其配置的基石。
Etcd以集群部署，节点间通信是通过Raft算法处理。在生产环境中，集群包含至少3个节点。在 thesecretlivesofdata.com/ 中使用动画很好地地解释了Raft算法如何运作以及整个集群的生命周期，包含以下几点
在Kubernetes集群的背景下，etcd实例可以作为Pod被部署在master节点上。下面是我们这篇文章会使用的Kubernetes模型。
如果想增加安全校验与弹性伸缩的功能的话，也可以将etcd部署成一个内部集群。
下面这个时序图来自Hepio的博客，展示了当一个Pod被创建的时候，Kubernetes内部模块之间的处理流程，形象地阐述了API Server和etcd之间的相互作用。
这个部分我们使用在DigitalOcean的kubeadm创建一个3节点的Kubernetes测试集群，选择weavenet作为网络附加组件。这个集群的etcd运行在master节点上。我们并没有配置一个真实环境的HA集群，但已经足够我们去探索etcd的数据存储功能了。
$ kubectl get nodes NAME STATUS ROLES AGE VERSION node-01 Ready master 56m v1.15.2 node-02 Ready <none> 2m17 v1.15.2 node-03 Ready <none> 2m17 v1.15.2
Etcd Pod
首先，我们将集群中所有正在运行的Pods先列出来：
$ kubectl get pods --all-namespaces NAMESPACE NAME READY STATUS RESTART AGE kube-system coredns-5c98db65d4–5kjjv 1/1 Running 0 57m kube-system coredns-5c98db65d4–88hkq 1/1 Running 0 57m kube-system etcd-node-01 1/1 Running 0 56m kube-system kube-apiserver-node-01 1/1 Running 0 56m kube-system kube-controller-manager-node-01 1/1 Running 0 56m kube-system kube-proxy-7642v 1/1 Running 0 3m kube-system kube-proxy-jsp4r 1/1 Running 0 3m kube-system kube-proxy-xj8qm 1/1 Running 0 57m kube-system kube-scheduler-node-01 1/1 Running 0 56m kube-system weave-net-2hvbx 2/2 Running 0 87s kube-system weave-net-5mrjl 2/2 Running 0 87s kube-system weave-net-c76fx 2/2 Running 0 87s
当一个集群刚被初始化的时候，只有在namespace为kube-system中的Pod是运行状态的。这些Pod是用来作为集群的任务管理的。我们比较关心的Pod是etcd-node-01，他是一个ectd的实例，用于存储集群状态。
我们运行一个shell命令，进入到这个Pod里面并且查看这个ctcd container的配置
通过使用--advertise-client-urls标识我们可以拿到所有的key/value对，通过etcdctl命令将他们保存到etcd-kv.json中
$ 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
我们快速查看一下这个文件，所有的key对应的values，并且所有都编码成了base64。
我们先获取所有的key到一个text文件里面看看他们都长什么样子，我将所有的key都列出来了，所以有点点长。
$ 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 # 后面有很多，已省略 ...
上面显示了一共342个定义在配置文件中的key，包含所有在集群里面的资源：
如果我们选择以上其中一个key，我们可以得到具体与之关联的value通过以下命令：
$ 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"
举个例子，我们想获得/registry/deployments/kube-system/coredns这个key的value
如果我们将这个对应的value解码出来发现信息其实可读性不高，一些图表不能被正常解码显示，但当然，Kubernetes内部是知道如何正确处理他们的。
从这个结果上看，我们可以推断出这个key是用来存储credns这个Pod的规则以及部署状态的。
让我们一起来创建一个Pod，看看集群的状态修改了什么以及有什么新的key的增加。
$ cat <<EoF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
name: www
spec:
containers:
- name: nginx
image: nginx:1.16-alpine
EoF
和之前一样的命令，我们获取所有的key并保存在etcd-kv-after-nginx-pod.json中。快速对比一下我们创建Pod之前的key列表和我们创建完wwwPod以后多了什么信息。
> /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
5个event以及一个pod被创建了，并且看上去也十分合理。我们更深入地看一下，从解码event key所对应的value开始，按照时间排序，我们可以看到他们做了下面的事情：
default/www到node-02nginx:1.16-alpinenginx:1.16-alpinenginxcontainer这些事件可以通过下面命令查看：
kubectl describe pod www
最后一个key，/registry/pods/default/www，提供了这个新创建的pod的所有信息
（依然解码出来可读性很糟糕。）
这篇文章的目的不是深入etcd，而是解释了一小部分Kubernetes内部包含了什么信息以及这些信息是怎么被组织起来的。希望能填补你对Kubernetes的一小片空白。
标签：ash Kubernete data 作用 初始 tar int sources pen
原文地址：https://www.cnblogs.com/k8s/p/12181412.html
