kubernetes 实战[1]

转载自笔者的博客

kubernetes 容器平台分析

Docker 容器算是目前最火的云计算产品了，因为它解决了很多运维和开发上的痛点问题，比如抹平了开发和生产的环境区别，甚至可以做到在生产环境使用 RHEL，而开发使用 Ubuntu，也能平滑部署，但是想要真正的将其投放到生产环境中，实际上还有很多问题亟待解决。而 kubernetes 就是这样一个 Best Practise

生产环境容器化的需求

脱离了业务环境的架构都是耍流氓，想要将容器真正落地，就需要真正分析其需求，这里就整理了一下容器化平台的需求

1. 存储

2. 网络

3. 容器编排和服务发现

4. 负载均衡

5. 日志收集

6. 认证授权

7. 资源配额

8. 分布式服务

可以看到，真正想要部署一个容器平台实际上需要解决的问题是十分繁多的，Docker 只是解决了最根本的容器分发和运行，但是 kubernetes 却解决了上面的大部分问题，这里就一一讲述一下。

存储

容器都是无状态的，很容易就被杀死，然后重新启动，因此存储是重中之重，Docker 自身提供了名为数据卷的存储方案，但是实际上没什么用，因为它支持的最好的就是本地存储，挂在本地路径，这样的强依赖是不可能做到生产环境的分布式服务的，除非每一台容器节点都持有一份同样的文件存储，但是这样会大大的消耗存储空间，而且 Docker 在文件权限管理等方面也有很多问题。kubernetes 提出的方案是通过持久化存储链，实际上就是做了个抽象层插件，各方可以开发自己的插件用于支持各类存储工具，目前已经支持 ceph、glusterfs 等主流的分布式文件系统了，但是这些分布式文件系统在部署上都很麻烦，甚至有性能的损失，因此使用 nas 作为存储是最便捷性能最好的。

网络

网络也是容器平台的重点问题，因为不可能依靠一个容器提供所有的服务，比如一个容器提供了数据库和 web 服务，而且这样也不利于解耦，因此容器之间需要通过网络通信，用过 Docker 自身网络的都知道，Docker 实际上是通过网桥来实现容器之间网络通信的，默认设置是无法做到跨节点网络，但是可以通过设置 flannel 产生一个 SDN，然后 Docker 使用此网络作为容器的网络，这样便能做到跨界点通信，kubernetes 则定义了一套 CNI 标准，只要符合这套标准就能让 kubernetes 使用 SDN，而目前来说已经有很多软件定义网络实现了这套协议，比如 flannel、weave，不过目前而言最好用的还是 flannel。

容器编排和服务发现

容器之间存在依赖必然需要编排功能，这也是 kubernetes 重点解决的问题，在容器编排上，kubernetes 有 pod、controller 概念，pod 可以认为是抽象的容器，它有可变的 ip，并且容易被杀死重启。controller 则是控制 pod 运作的控制器，replication controller、deployment、statefulsets、daemon sets，各有各的用法，比如 deployment 能够做到水平伸缩。在服务发现上面，kubernetes 有 pod、service 概念，看到这里相信大家都会有疑问，pod ip 可变总不能每次都要手动改程序或者配置才能访问吧，实际上 kubernetes 提供的 service 就是用来解决这个问题的，service 是一套虚拟的 ip，service 通过 selector 选择器挑选出自己身后的 pod，这样就能做到提供稳固的 ip 接口，其他容器无需关心数据库的 ip，只需要关心数据库这个 service 就可以。service 本身的 ip 则不是通过 SDN 产生的，而是通过 iptables 导流，将其导入到实际的 pod 中，但是这样子依旧存在一个问题，就是 service 的 ip 同样需要提前知道，这时候就需要服务发现出马了，kubernetes 自身提供了一套简单好用的 DNS 发现机制，kube-dns 将 service 注册到 dns 中，通过 dns 就能解析得到 service 对应的 ip。

负载均衡

负载均衡实际上就是需要一个前端负载均衡器，将流量统一导入到不同的容器中，kubernetes 的方案是通过 ingress 定义规则，然后根据规则产生模板配置，就比如 nginx 作为负载均衡器，产生配置后 reload 就能生效，但是目前官方提供的 ingress controller 容器镜像存在着一个问题，当 ingress 定义一个 TCP/UDP 四层负载均衡转发的时候，nginx 容器则必须修改容器部署，因为需要绑定主机端口。因此目前最好的方案还是通过云服务器提供商的负载均衡器，比如 GCE、AWS 提供的负载均衡器。

日志收集

日志收集实际上不光是收集容器通过标准输出标准错误产生的日志，还需要收集容器运行时信息，比如内存、cpu 占用等信息，这里不细讲了，因为无论是 Docker 还是 kubernetes 都提供了收集方案，不过 kubernetes 更加灵活好用，并且收集的信息更全面，连容器节点的信息都能收集

认证授权

kuberentes 有几大组件 apiserver、controller manager、scheduler、proxy、kubelet，所有的组件都通过 apiserver 通信和管理，因此需要通过认证和授权来防止非法操作，在这上面 kubernetes 提供了很多方案，比如 basic auth、bearar token、keystone 等，但是真正能投入生产环境使用的，只有 OpenID Connector，不知道这种认证授权的可以自行谷歌，更糟的是，官方甚至没有提供部署方案，需要自行研发 OpenID Connector 服务器并且部署下去。CoreOS 倒是开源了一套 dex 系统，但是这玩意实际上也不靠谱，照样需要研发力量的支持，从这上面就决定了 kubernetes 高门槛的准入标准。

资源配额

kubernetes 资源配额方案非常丰富，无论是存储配额还是内存甚至是 cpu 限额，都可以通过 yaml 文件定义

分布式服务

分布式服务是大规模运行容器平台的关键，因为容器平台必然是部署在多节点上的，而 kubernetes 天生就是为分布式部署开发的，apiserver、controller manager、scheduler 实际上就是主节点，而 proxy 和 kubelet 则是每个 slave 节点都需要的。不过目前主流的做法包括 kubeadm 半自动部署方案都是让主节点通过 kubelet 在容器中运行 apiserver 等东西。

总结

想要在生产环境大规模应用容器化技术，看似开源了产品，但是 kubernetes 本质上是一个半成品，甚至连自动化部署方案都不成熟，并且需要研发力量的支持才能真正运行起来，以笔者个人的意见来说，kubernetes 实际上并非是一个面向企业终端用户的产品，而是一个面向云计算厂商的半成品，它真正的用法应当是云计算公司提供自动化节点部署方案，云计算平台提供 SDN 、负载均衡和分布式存储，甚至可能的话，让云计算厂商提供一套管理控制 web 界面，并且做好认证授权系统，kube-dashboard 这个官方提供的 web ui 界面实际上功能是全了，但是认证授权功能的缺失则导致普通用户很难部署使用，或者说 kube-dashboard 本来就不是为了普通用户部署而开发的，而是为了提供给厂商做二次开发准备。kube-dashboard 则是负责定义 web 管理界面应该有哪些功能。