• [译]走进Kubernetes集群的大脑:Etcd


    英文原文:A Closer Look at Etcd: The Brain of a Kubernetes Cluster

    译文原文:[译]走进Kubernetes集群的大脑:Etcd

    译者:野生程序元

    Etcd是Kubernetes用于存储集群各种状态信息(配置信息,运行)一个很重要的组件,这篇文章,我们带领大家掀开Etcd的神秘面纱,理解他是如何存储这些各种各样的碎片信息的。

    Etcd的概况

    Etcd 是一个分布式的,依赖key-value存储的,最重要的分布式数据存储系统 

    -- etcd.io


    在Kubernetes的世界里面,etcd是服务发现集群状态存储以及其配置的基石。

    Etcd以集群部署,节点间通信是通过Raft算法处理。在生产环境中,集群包含至少3个节点。在 thesecretlivesofdata.com/ 中使用动画很好地地解释了Raft算法如何运作以及整个集群的生命周期,包含以下几点

    • leader节点的选举
    • 日志的复制与同步

    Kubernetes中的Etcd

    在Kubernetes集群的背景下,etcd实例可以作为Pod被部署在master节点上。下面是我们这篇文章会使用的Kubernetes模型。

    如果想增加安全校验与弹性伸缩的功能的话,也可以将etcd部署成一个内部集群。

    下面这个时序图来自Hepio的博客,展示了当一个Pod被创建的时候,Kubernetes内部模块之间的处理流程,形象地阐述了API Server和etcd之间的相互作用。

    Kubernetes测试集群

    这个部分我们使用在DigitalOceankubeadm创建一个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,包含所有在集群里面的资源:

    • Nodes
    • Namespaces
    • ServiceAccounts
    • Roles,RolesBindings, 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

    如果我们选择以上其中一个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

    让我们一起来创建一个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/wwwnode-02
    • 拉取镜像nginx:1.16-alpine
    • 成功拉取镜像nginx:1.16-alpine
    • 创建nginxcontainer
    • 启动这个container

    这些事件可以通过下面命令查看:

    kubectl describe pod www

    最后一个key,/registry/pods/default/www,提供了这个新创建的pod的所有信息

    • 最后使用的配置
    • 关联的token
    • 状态
    • ...

    (依然解码出来可读性很糟糕。)

    总结

    这篇文章的目的不是深入etcd,而是解释了一小部分Kubernetes内部包含了什么信息以及这些信息是怎么被组织起来的。希望能填补你对Kubernetes的一小片空白。

  • 相关阅读:
    从零开始通过webhooks实现前端自动化
    使用rem配置PC端自适应大屏
    Nuxt内导航栏的两种实现方式
    VueX中直接修改数据报错,修改一维数组,二维数组,报错的原因
    在mpvue或者Vue中使用VUEX
    小程序框架MpVue踩坑日记(二)
    小程序mpvue中动态切换echarts图表
    小程序踩坑之不同屏幕下动态改变translate值
    Koa2+MySQL+VUE+ElementIUI搭建简单的后台管理小系统
    小程序框架MpVue踩坑日记(一)
  • 原文地址:https://www.cnblogs.com/k8s/p/12181412.html
Copyright © 2020-2023  润新知