kubernetes in action 读后感

kubernetes in action 读后感

在2019年，偶然间接触到kubernetes技术。起初我是拒绝的，kubernetes集群搭建稍许繁琐；配置应用的yaml文件如此复杂；各种资源类型目不暇接。随着我一步步对kubernetes的了解，后来真香！复杂的应用就几个配置文件声明一下，等几分钟就可以访问到服务了；服务保持不间断的状态；许多与kubernetes配套的互补的解决方案等等。

在之后，在我读完《kubernetes in action》这本书之后，结合之前的了解，对kubernetes有了新的认识，现在就和大家分享一下：

kubernetes设计理念

1.解耦

• kubernetes有许多的控制组件（ReplicationController管理器，ReplicationSet管理器，Deployment管理器，StateFulset管理器，Node管理器，Service管理器，Endpoint管理器，Namespace管理器，persistentVolume管理器等等）各司其职。当我们向API服务器声明了关于这些管理器的配置时，APIServer会接收到相应的REST请求并发出声明，这些管理器会根据APIserver发出的声明创建出相应的资源，他们彼此独立，互不依赖（ReplicationSet管理器，Deployment管理器还是有一定联系的）。

2.资源集中管理

• kubernetes对于卷存储，秘钥，配置，pod资源用量，pod权限等等。它们都可以通过声明成为集群资源或者一种约定，当我们创建pod时，可以通过简单的方式使用这些资源以及自动的遵守设定的约定。

3.应用程序对kubernetes无感知

• 研发人员不用关注每个应用所处的环境，虽然说获取环境信息不会像在真实的操作系统那样方便，但是kubernetes也提供了极其方便的获取环境变量的方式（通过pod内部与API服务器进行交互，获取元数据）

• 应用之间的通信不用通过IP+端口，而是利用service做简单的配置，即使pod重新调度，之前service配置的关系也会将请求转发到相应的pod，应用程序不需要关系自己在哪个节点。

4.kubernetes对应用的状态是声明式的

• 我们如果想要集群达到什么状态，只需要通过APIserver帮助我们声明我们的请求，之后的工作由各组件相互协调最终达到你期望的样子。例如我们声明一个deployment资源：用户通过kubectl 或其他API客户端将请求发送给API Srtver。API Server将请求存储在etcd中，etcd反回确认消息，之后API Server申明此请求，kubernetes的Deployment控制器通过“watch”来获取API Server的变化，创建ReplicaSet控制器，控制器会基于ReplicationSet创建的pod模板创建pod资源。之后kube-scheduler为请求所要创建的pod选择一个node节点，并反馈给API Server，API Server将信息存储到etcd中，收到确认消息之后再声明此次调度信息。之后相应节点上的kubelet调用相应节点中的Docker Engine来创建启动容器组成pod。创建完成后将信息返回给API Server并存储到etcd中，etcd确认收到消息，返回确认信息给API Server，API Server将确认信息返回给kubelet。

5.冗余机制

• 无论是pod亲和性调度，或者应用更新，亦或是kubernetes核心组件（etcd，master等），它们都强调一种冗余机制，即使节点宕机，应用更新失败，脑裂等突发状况，总会有至少一个pod持续提供服务，在一段时间后，kubernetes会尽量让集群达到你声明的状态。

6.易拓展性

• kubernetes的pod支持横向拓展和纵向拓展，动态的抵御流量或者负载对于应用的压力
• kubernetes的组件etcd，网络组件CNI，日志收集插件，监控插件等等，都是可以用其他技术替代的（从kubernetes刚开发到现在版本，这些功能都在寻找更好的技术来实现，比如flannel，Prometheus，EFK，sidecar等），这使得kubernetes能够很好的融合新的先进技术。

kubernetes可以解决什么样的问题

应用在开发人员完成并经历过测试之后，需要经历这几个步骤才可以很好的被用户使用。

1.部署

• 将应用部署到哪里

  kubernetes提供了污点和污点容忍，pod与node之间亲和性调度和非亲和性调度，pod和pod亲和性调度和非亲和性调度，以及基于每个节点的各个参数算出的比重值进行调度

• 如何部署应用，以及解决应用的依赖性

  在pod中加入init容器来保证容器顺序启动

• 检测部署成功

  可以在pod里设置就绪探针，存活探针等，设置失败策略

2.运行

• 应用保持一直运行的状态

  kubernetes里ReplicationSet控制器会保证pod的数量符合预期，当有pod不能工作时会重新调度pod

• 应用的流量，负载

  kubernetes提供了横向和纵向扩容缩容（HPA，VPA）

• 应用挂掉之后，再次启动保持原来的状态

  kubernetes允许创建有状态的应用（Statefulset），它们挂载一个持久卷，当应用重启或重新调度时，相应的持久卷会被重新挂载上

3.更新

• 无感知更新

  可以使用deployment进行滚动更新以及控制滚动更新的速率，在更新出错时，也可以快速进行回滚恢复（更新过后，会保存ReplicationSet副本，可以快速进行恢复）

• 灰度发布

  利用service控制器通过label对流量进行分配到匹配标签的pod

4.维护

• 如何进行监控

  利用Prometheus监控kubernetes集群

• 如何进行日志收集

  EFK或者是sidecar

kubernetes我认为不足的地方

1.yaml文件配置起来稍显复杂，字段的命名方式有些比较奇怪（helm据说可以简单一点）

2.在国内因为防火墙的原因，总是出现镜像下载缓慢，失败的情况

结语

kubernetes所有的设计都是为了解放人力，让研发，测试，运维可以高效的协同工作，通过一项项配置使得原来手动做的工作变得自动，让原来难以管理的容器变得易于管理。虽然从提出概念到现在已经经历了许久时间，许多公司原来的架构体系完全可以满足需求。但是当我打开一个个开源软件软件官网，在安装配置选项都有kubernetes的身影，国内一些云服务厂商也在支持kubernetes。kubernetes已经不是如此的神秘。我相信用过的都会说真香！