kubernetes 实战[1]

摘要：不过目前主流的做法包括半自动部署方案都是让主节点通过在容器中运行等东西。

转载自笔者的博客

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

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

存储

网络

容器编排和服务发现

负载均衡

日志收集

认证授权

资源配额

分布式服务

可以看到，真正想要部署一个容器平台实际上需要解决的问题是十分繁多的，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 管理界面应该有哪些功能。