Kubernetes 实战[1]


本章转载自我的博客

Kubernetes 容器平台分析

【深圳站|3天烧脑式Kubernetes训练营】培训内容包括:Kubernetes概述、架构、日志和监控,部署、自动驾驶、服务发现、网络方案等核心机制分析,进阶篇——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 更加灵活好用,并且收集的信息更全面,连容器节点的信息都能收集

认证授权

Kubernetes 有几大组件 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 管理界面应该有哪些功能。

0 个评论

要回复文章请先登录注册