学习了这么多etcd，就是为了学习etcd在k8s中的作用。

k8s的部署架构

部署架构

从部署架构中可以看到有组件：

• ApiServer，提供了增删改查及watch接口，是各个组件的交互枢纽，同时提供认证、授权、准入、限速功能。
• etcd，负责元数据的存储，k8s的状态数据全部存储在etcd上。
• Controller-Manager，包含了各种控制器，就是使用监听，使得资源的实际状态和期望状态一致。
• Scheduler，调度资源，负责Pod的调度，当有Pod需要调度时，通过一系列的筛选和评优算法，为Pod分配最佳的Node。
• node节点，部署有kubelete，负责pod的创建运行；kubelet-proxy，负责节点上网络代理；另外还有容器运行时、各种插件

etcd作为k8s存储

etcd作为k8s存储，主要存储k8s元数据，通过学习etcd我们指导，etcd一般最佳内存在8G，太大太小都容易引起性能降低。所以我们不能拿etcd当做数据库使用，只能存储各种元数据信息。
按照k8s的官方文档和业界的最佳实践，k8s可以管理到5000个节点，这么算每个节点可以分配到16M的存储。

按照etcd学习的知识，etcd存储的key、value值，那么k8s的key长什么样呢？
在etcd中，资源命名是这样的

prefix + "/" + 资源类型 + "/" + namespace + "/" + 具体资源名
例如：
/registry/deployments/default/helloworld

我们学习了etcd的get有按照key查找和按照范围查找两种方式，当我们用kubctl命令时

• kubectl get deployments -n default 这条到了etcd中，就对应etcdctl get --prefix /registry/deployments/default
• kubectl get deployments/helloworld，这条到了etcd中，对应etcdctl get --prefix /registry/deployments/default/helloworld
• kubectl get deployments -l hello:hello, 这条到了etcd中，对应于etcdctl get --prefix /registry/deployments/default，然后将结果根据标签hello:hello过滤

etcd在k8s中交互

etcd在k8s中什么时机交互呢？

pod创建流程

如上图，一个Pod的创建过程：

• user通过kubectl或者APIServer提供的调用接口创建Pod
• APIServer通过鉴权等后，构建出完整的Pod信息，并将该信息存储到etcd中。
• Scheduler已经在watch pod的事件，发现有新的pod创建信息， 随即为该pod分配合适的node，然后调用APIServer的修改接口，将Pod与node绑定
• 被分配node上的kubelet已经在watch pod事件，发现本节点的pod创建事件，开始调用运行时，创建pod。

从上面过程可以看到两点：

• APIServer反复出现的原因是因为所有的组件都只和APIServer交互，除此之外并不两两交互
• watch是个很重要的功能，Scheduler、Controller-Manager、kubelet组件都通过watch来检测变化做出响应。

从设计的角度来看，这也是一种异步编程方式，和我们在应用开发中收到MQ消息，然后进行响应是一致的。只不过这里的异步处理都建立在etcd的watch机制上。

小结

etcd是k8s的状态存储库，同时其watch机制也是k8s异步设计的基础。etcd在k8s中，还有很多工程场景需要学习和理解，下节继续学习。