kubernets 相关技术调研

发表于 2020-03-01 分类于技术 Disqus：本文字数： 27k 阅读时长 ≈ 24 分钟

俗话说文档写得好，同行抄到老 😂。

在前期的技术选型调研过程中，对 K8s 密切相关的解决方案：网络插件、存储解决方案、监控告警系统、日志收集和处理、持续集成和交付系统等做了充分的调研和测试工作，现如今总结一下调研过程中的记录。

参考

俗话说文档写得好，同行抄到老 😂。不过咱木子还是有点原则的，最起码标注引用来源，尊重原作者的版权。所以就在此罗列了本文剽窃引用的来源。由于是技术调研，文中提到的相关开源软件介绍多数都是引用自官方文档或者英文翻译的文档。具体的细节稍后再更新博客补充。本文的内容涉及比较多，主要参考和引用了以下站点。

站点	主要内容	印象
Jimmy Song - 宋净超的博客	微服务、服务网格、云原生	蚂蚁金服云原生布道师
Cloud Native Wiki	云原生百科、图书、编年史	蚂蚁金服云原生布道师
敖小剑的博客	微服务、服务网格、云原生	蚂蚁金服云原生布道师
云原生实验室 - 米开朗基杨的博客	Cloud Native	云原生布道师
zhangguanzhang’s Blog	Kubernetes、嵌入式、Linux	张馆长 😂
漠然的博客 mritd Blog	Kubernetes、Golang	Java Web 开发者 1 枚
MoeLove	Kubernetes 生态相关、开源	每周坚持周报 👍
KaiRen’s Blog	Kubernetes、Docker 容器	台湾博主
Hwchiu Learning Note	Kubernetes、SDN、DevOps	台湾博主
Kakashi’s Blog	AWS、Kubernetes、Prometheus	台湾博主
Aylei’s Blog	Kubernetes、云原生、TiDB	在 PingCAP 的阿磊
青木のJava 小屋	SpringCloud on Kubernetes	打杂程序猿
开元 DevOps 知识库
起风了
茶歇驿站
Polar Snow Documentation
DevOps – 成长之路
梦旭随想	Kubernetes 、容器	无栈工程师 😂
我爱西红柿
Bingo Huang	Golang、Docker	一个程序员的自我修养
国南之境	CoreDNS 、Kubernetes、Golang
博客高策	机器学习、Kubernetes、kubebuilder	江湖小虾米
birdben
浮生若梦
ictfox blog
杜屹东的博客学无止境
CloudNative 架构
Doublemine
Arthur Chunqi Li’s Blog
Archive Arthur Chunqi Li’s Blog
IT 技术工作学习折腾笔记李佶澳的博客
墨荷琼林官网-编程日志
Archive - Nolla
Tomoya’s Blog
君无止境
Jamin Zhang
roc 的博客 - imroc.io	《Kubernetes 实践指南》、算法
Blog - Sysdig
sleele 的博客
TauCeti blog · TauCeti blog
Solar
Infvie’s Blog 运维 SRE 社区博客
水晶命匣
苏洋博客
Zlatan Eevee

开源容器平台

OpenShift

简介

OpenShift 是红帽的云开发平台即服务（PaaS）。通过 OpenShift，企业可以快速搭建稳定、安全、高效的容器应用平台。在这个平台上：

可以构建企业内部的容器应用市场，为开发人员快速提供应用开发所依赖的中间件、数据库等服务。
通过自动化的流程，开发人员可以快速进行应用的构建、容器化及部署。
通过 OpenShift，用户可以贯通从应用开发到测试，再到上线的全流程，开发、测试和运维等不同的角色可以在一个平台上进行协作。
支持 LDAP 用户权限管理，支持细粒度的权限资源管理。
OpenShift 可以提高应用从研发到上线的效率和速度，缩短产品上市的时间，可以有效地帮助企业推进 DevOps，提高资源利用率，提升生产效率。

KubeSphere 是在目前主流容器调度平台 Kubernetes 之上构建的企业级分布式多租户容器平台，提供简单易用的操作界面以及向导式操作方式，在降低用户使用容器调度平台学习成本的同时，极大减轻开发、测试、运维的日常工作的复杂度，旨在解决 Kubernetes 本身存在的存储、网络、安全和易用性等痛点。除此之外，平台已经整合并优化了多个适用于容器场景的功能模块，以完整的解决方案帮助企业轻松应对敏捷开发与自动化运维、微服务治理、多租户管理、工作负载和集群管理、服务与网络管理、应用编排与管理、镜像仓库管理和存储管理等业务场景。

KubeSphere 高级版提供企业级容器应用管理服务，支持更强大的功能和灵活的配置，满足企业复杂的业务需求。比如支持 Master 和 etcd 节点高可用、可视化 CI/CD 流水线、多维度监控告警日志、多租户管理、LDAP 集成、新增支持 HPA (水平自动伸缩) 、容器健康检查以及 Secrets、ConfigMaps 的配置管理等功能，新增微服务治理、灰度发布、s2i、代码质量检查等，后续还将提供和支持多集群管理、大数据、人工智能等更为复杂的业务场景。

Rancher

简介

Rancher 是一个开源的企业级多集群 Kubernetes 管理平台。通过 Rancher，企业再也不必自己使用一系列的开源软件去从头搭建容器服务平台。它提供了在生产环境中使用的管理 Docker 和 Kubernetes 的全栈化容器部署与管理平台。它可以帮助企业在生产环境中轻松快捷的部署和管理容器，轻松地管理各种环境的 Kubernetes ，满足 IT 需求并为 DevOps 团队提供支持。

部署工具

RKE

RKE 全称为 Rancher Kubernetes Engine，是 Rancher 开源的轻量级 K8s 集群部署工具，使用它可以快速的部署一个 K8s 集群。参考文档使用 RKE 部署一个 K8s 集群并部署 Rancher HA 。

Kops

kops 是一个生产级 Kubernetes 集群部署工具，可以在 AWS、GCE、VMWare vSphere 等平台上自动部署高可用的 Kubernetes 集群。主要功能包括：

命令行自动补全
全自动安装流程
使用 DNS 识别集群
支持自定义扩展 add-ons
支持高可用 - 参考 high_availability.md
dry-run 和自动幂等升级等基于状态同步模型
支持从 kube-up 创建的集群升级到 kops 版本
自动部署高可用的 Kubernetes 集群
自我修复：一切都在自动扩展组中运行
可以直接提供或者生成 terraform 清单 - 参考 terraform.md
支持多种操作系统（如 Debian、Ubuntu 16.04、CentOS、RHEL、Amazon Linux 和 CoreOS）

Kubeadm

Kubeadm 是 Kubernetes 官方推出的集群部署工具，在 1.14.0 版本之后就已经达到生产可用 GA 的稳定性。对于刚刚接触 Kubernetes 的人员来说，Kubeadm 无疑是个好工具。需要注意的是 kubeadm 所需要的镜像是在 gcr.k8s.io 上的，被 GFW 给墙掉了，可以将镜像从墙外的台服务器上搞下来，然后通过 docker load 的方式加载镜像，这样就不会因为无法 pull 镜像 pod 一直处在 pending 状态。

sealos

sealos 基于 kubeadm 来部署，旨在做一个简单干净轻量级稳定的 kubernetes 安装工具，能很好的支持高可用安装。特性如下：

证书延期
使用简单，支持自定义配置
内核负载，极其稳定，因为简单所以排查问题也极其简单
支持离线安装，工具与资源包（二进制程序配置文件镜像 yaml 文件等）分离,这样不同版本替换不同离线包即可

kubeasz

使用 Ansible 脚本安装 K8s 集群，介绍组件交互原理，方便直接，不受国内网络环境影响。是目前 kubernetes 中文社区最为热门的部署工具，GitHub 上的 start 数超过了 4K5 。基于二进制方式部署和利用 ansible-playbook 实现自动化；既提供一键安装脚本, 也可以根据 安装指南 分步执行安装各个组件。

集群特性 TLS 双向认证、RBAC 授权、多 Master 高可用、支持 Network Policy、备份恢复、离线安装
集群版本 kubernetes v1.13, v1.14, v1.15, v1.16
操作系统 CentOS/RedHat 7, Debian 9/10, Ubuntu 1604/1804
运行时 docker 18.06.x-ce, 18.09.x, containerd 1.2.6
网络 calico, cilium, flannel, kube-ovn, kube-router

kubespray

Kubespray 是 Kubernetes incubator 中的项目，也是 kubernetes 官方出品。目标是提供生产可用 Kubernetes 部署方案，该项目基础是通过 Ansible Playbook 来定义系统与 Kubernetes 集群部署的任务，具有以下几个特点：

可以部署在 AWS, GCE, Azure, OpenStack 以及裸机上.
部署 High Available Kubernetes 集群.
可组合性 (Composable)，可自行选择 Network Plugin (flannel, calico, canal, weave) 来部署.
支持多种 Linux distributions(CoreOS, Debian Jessie, Ubuntu 16.04, CentOS/RHEL7).

不过由于是国外开发者维护，有些软件包因为网络原因无法下载下来所以会比较麻烦。所以国内用户不建议触碰，除非你再去手动修改那些软件包的源为国内的。

稳定版本选择

可以参照这张表格，来选择小版本号介于 5~~8 之间且还在维护的版本。比如 v1.16.7 ，有 CVE 安全漏洞之前的版本也不建议使用。

month	stable	stable	stable	stable
2020-02	v1.17.3	v1.16.7	v1.15.10
2020-01	v1.17.2 v1.17.1	v1.16.6 v1.16.5	v1.15.9 v1.15.8	CVE
2019-12	v1.17.0	v1.16.4	v1.15.7	v1.14.10
2019-11	v1.16.3	v1.15.6	v1.14.9
2019-10	v1.16.1 v1.16.2	v1.15.5	v1.14.8	v1.13.12
2019-09	v1.16.0	v1.15.4	v1.14.7	v1.13.11
2019-08	v1.15.2 v1.15.3	v1.14.5 v1.14.6	v1.13.9 v1.13.10	CVE
2019-07	v1.15.1	v1.14.4	v1.13.8	v1.12.10
2019-06	v1.15.0	v1.14.3	v1.13.7

1.14.10

上游进展

对 Windows Node 和 container 的支持达到生产级别，支持 Windows Server 2019；
本地持久化数据卷正式可用，这可以方便使用本地 SSD 之类的存储，但注意这个特性容错性较差；
Pod 优先级和抢占机制正式可用，(建议慎重使用)；
Pod Ready++ (Pod Readiness Gates) 达到稳定，可以更好的判断 Pod 及其需要的资源是否均已就绪；

1.15.7

上游进展

v1.15 版本由 25 个增强功能组成，其中 2 个移动到 stable ，13 个 beta 以及 10 个 alpha ，整体上集中于稳定性改进和扩展的增强。
CRD (Custom Resource Definition) 是 Kubernetes 提供的一种可用于扩展其能力的方式，当前有很多使用 CRD 构建于 Kubernetes 上的平台/系统，可以说之后对 Kubernetes 的扩展，或者说想要基于 Kubernetes 开发，同时又想与上游保持同步的话，CRD 是个最佳的选择。
Kubeadm 在此版本开始有了自己独立的 LOGO ，同时在这个版本中 kubeadm 的功能也得到了很多的完善和补充。这使得 kubeadm 成为更普遍/更好用的搭建集群的工具，同时对集群生命周期的管理也做的更加到位了。

1.16.5

上游进展

CRD 达到 GA ，这是当前社区最为推崇的一种扩展 Kubernetes 的方式，并且自从 1.7 加入后，也被越来越广泛的使用了；
准入控制 webhooks 达到 GA ，准入控制在 Kubernetes 中太过于重要了，自 1.9 该功能加入以来，被广泛用于扩展 Kubernetes 相关功能；
现在 CSI 规范中支持调整卷大小，当前正在迁移至 Beta 阶段；
IPv4/IPv6 双栈支持；
为了更好的控制 kube-apiserver 的网络流量，正在尝试给它增加一个代理，详情可点击链接查看；
现在 kubeadm 在 TLS bootstrap 之后，将会删除 bootstrap-kubelet.conf，如果有依赖此文件的小伙伴，请尽快迁移使用 kubelet.conf ，此外也建议先看看 RBAC 相关的内容，了解下切换的意义；
beta.kubernetes.io/metadata-proxy-ready 和 beta.kubernetes.io/kube-proxy-ds-ready 都被移除了；
还有之前提到过的 pps/v1beta1 和 apps/v1beta2 已经被 apps/v1 取代等，这里不再一一列举了，有兴趣可参考之前的周报内容。

1.17.0

上游进展

Kubernetes v1.17 包含 22 个增强功能，其中 14 个已经 stable ，4 个 beta 以及剩余 4 个 alpha 。
#87714 kubectl 的 --server-dry-run 被标记为废弃，并且可以通过使用 --dry-run=server 替代。并且 kubectl 的 --dry-run 参数接收的值，也变成了 client, server 以及 none；
#86810 kubeadm config images list 实现了结构化输出，支持文本，JSON，YAML 和 GO 模板等。（我个人认为，这个功能不错的，但目前我还没想到什么情况下我会需要它）；
#87975 kubeadm upgrade node config 从 v1.15 起标记废弃，现在正式移除，请使用 kubeadm upgrade node phase kubelet-config 代替。

关于上有进展引用自 K8s 生态周报，推荐各位去关注。

节点 OS

Photon OS

特性

Photon OS 是 VMware 团队对 vSphere ESXi 虚拟化平台专门打造的容器优化型操作系统，从目前的使用来看是基于 RHEL 或 CentOS 系的发行版。针对 ESXi 虚拟胡优化内核，理论上在 vSphere ESXi 虚拟化上 Photon OS 要比传统的 CentOS/Ubuntu 发行版性能要好一些，系统占用的资源也少一些。另外 Photon OS V3.0 的内核是 4.19 版本的，使用方式和 CentOS 差别不大。

Photon OS™ is an open source Linux container host optimized for cloud-native applications, cloud platforms, and VMware infrastructure. Photon OS provides a secure run-time environment for efficiently running containers. Some of the key highlights of Photon OS are:

Optimized for VMware hypervisor: The Linux kernel is tuned for performance when Photon OS runs on VMware ESXi.

Support for containers: Photon OS includes the Docker daemon and works with container orchestration frameworks, such as Mesos and Kubernetes.

Efficient lifecycle management: Photon OS is easy to manage, patch, and update, using the tdnf package manager and the Photon Management Daemon (pmd).

Security hardened: Photon OS provides secure and up-to-date kernel and other packages, and its policies are designed to govern the system securely.

For an overview of Photon OS, see https://vmware.github.io/photon/

CoreOS

CoreOS 是以安全性、一致性、可靠性为设计目标的一款操作系统。因为 CoreOS 的设计初衷只为运行应用容器，因此需要安装很少系统级别的依赖包即可。相比典型的 Linux 服务器，这就意味着 CoreOS 需要很低耗的 CPU 和高效的 RAM 即可满足需求。CoreOS 几乎可以运行在包括 Vagrant, Amazon EC2, QEMU/KVM, VMware, OpenStack 的任何平台，甚至在未安装任何软件的裸机硬件环境都可以。

最小化操作系统：CoreOS 被设计成一个基于容器的最小化的现代操作系统。它比现有的 Linux 安装平均节省 40% 的 RAM（大约 114M ）并允许从 PXE 或 iPXE 非常快速的启动。
CoreOS 采用主动/被动双分区方案来实现自动更新。自动更新以单一体为单位，而不是通过逐包替换的方式进行。稍后我们将详细介绍这个。
CoreOS 使用 Linux 容器在更高抽象层次上管理服务，而没有采用通过 yum 或者 APT 工具做包的安装管理。单一的服务代码以及它所有的依赖会被打包到一个容器中，打包进入容器后就可以运行在单一的 CoreOS 机器，也可以运行在 CoreOS 集群中。
Linux 容器提供与完整虚拟机相似的功能。但是容器聚焦在应用程序层次，而不是整个虚拟主机层次。因为容器不能运行独立的 Linux 内核，不需要一个中间件层，因此它几乎没有性能上的开销。低性能开销的特质意味着可以部署更少的机器、使用配置低的机器就可以完成虚拟机同样的功能，从而降低成本。

Rancher OS

RancherOS 是 Rancher 团队所维护的开源项目，也是对标 CoreOS 一样，专门用来运行容器，并且可以运行在生产环境（至少官方做了这么样的承诺，咱也没在生产用过，不好说。在 RancherOS 中所有的进程（包括系统所有的服务，比如 udev 和 syslog）都是用 docker 来管理，这一点要比 CoreOS 更加激进一些，而 CoreOS 还是使用传统 Linux 发行版中的 systemd 来管理系统中的服务。通过移除传统 Linux 发行版中不必要的服务和库来最小化系统，使他专注单一的功能，即运行 docker 容器。

RancherOS is the smallest, easiest way to run Docker in production. Every process in RancherOS is a container managed by Docker. This includes system services such as udev and syslog. Because it only includes the services necessary to run Docker, RancherOS is significantly smaller than most traditional operating systems. By removing unnecessary libraries and services, requirements for security patches and other maintenance are also reduced. This is possible because, with Docker, users typically package all necessary libraries into their containers.

Another way in which RancherOS is designed specifically for running Docker is that it always runs the latest version of Docker. This allows users to take advantage of the latest Docker capabilities and bug fixes.

Like other minimalist Linux distributions, RancherOS boots incredibly quickly. Starting Docker containers is nearly instant, similar to starting any other process. This speed is ideal for organizations adopting microservices and autoscaling.

Docker is an open-source platform designed for developers, system admins, and DevOps. It is used to build, ship, and run containers, using a simple and powerful command line interface (CLI). To get started with Docker, please visit the Docker user guide.

高可用架构

参考

关于 Kubernetes Master 高可用的一些策略

这张图从管理平面、执行平面和数据平面三个部分来简单说明一下该高可用架构方案以及各个组件的功能。

etcd 高可用

etcd 是 Kubernetes 当中唯一带状态的服务，也是高可用的难点。Kubernetes 选用 etcd 作为它的后端数据存储仓库正是看重了其使用分布式架构，没有单点故障的特性。etcd 的高可用基本有三种思路：

独立的 etcd 集群

使用 3 台或者 5 台服务器只运行 etcd，独立维护和升级。甚至可以使用 CoreOS 的 update-engine 和 locksmith，让服务器完全自主的完成升级。这个 etcd 集群将作为基石用于构建整个集群。采用这项策略的主要动机是 etcd 集群的节点增减都需要显式的通知集群，保证 etcd 集群节点稳定可以更方便的用程序完成集群滚动升级，减轻维护负担。

Master 节点 static pod 形式

二是在 Kubernetes Master 上用 static pod 的形式来运行 etcd，并将多台 Kubernetes Master 上的 etcd 组成集群。在这一模式下，各个服务器的 etcd 实例被注册进了 Kubernetes 当中，虽然无法直接使用 kubectl 来管理这部分实例，但是监控以及日志搜集组件均可正常工作。在这一模式运行下的 etcd 可管理性更强。

self-hosted etcd 方案

三是使用 CoreOS 提出的 self-hosted etcd 方案，将本应在底层为 Kubernetes 提供服务的 etcd 运行在 Kubernetes 之上。实现 Kubernetes 对自身依赖组件的管理。在这一模式下的 etcd 集群可以直接使用 etcd-operator 来自动化运维，最符合 Kubernetes 的使用习惯。

这三种思路均可以实现 etcd 高可用的目标，但是在选择过程中却要根据实际情况做出一些判断。简单来讲硬件资源充足但保守的项目选方案一，想一步到位并愿意承担一定风险的项目选方案三。折中一点选方案二。

kube-apiserver 高可用

apiserver 本身是一个无状态服务，要实现其高可用相对要容易一些，难点在于如何将运行在多台服务器上的 apiserver 用一个统一的外部入口暴露给所有 Node 节点。

说是难点，其实对于这种无状态服务的高可用，我们在设计业务系统的高可用方案时已经有了相当多的经验积累。需要注意的是 apiserver 所使用的 SSL 证书要包含外部入口的地址，不然 Node 节点无法正常访问 apiserver。

apiserver 的高可用也有三种基本思路：

使用外部负载均衡器

一是使用外部负载均衡器，不管是使用公有云提供的负载均衡器服务或是在私有云中使用 LVS 或者 HaProxy 自建负载均衡器都可以归到这一类。负载均衡器是非常成熟的方案，在这里略过不做过多介绍。如何保证负载均衡器的高可用，则是选择这一方案需要考虑的新问题。

在网络层做负载均衡

二是在网络层做负载均衡。比如在 Master 节点上用 BGP 做 ECMP，或者在 Node 节点上用 iptables 做 NAT 都可以实现。采用这一方案不需要额外的外部服务，但是对网络配置有一定的要求。

在 Node 节点上使用反向代理对多个 Master 做负载均衡

三是在 Node 节点上使用反向代理对多个 Master 做负载均衡。这一方案同样不需要依赖外部的组件，但是当 Master 节点有增减时，如何动态配置 Node 节点上的负载均衡器成为了另外一个需要解决的问题。

从目前各个集群管理工具的选择来看，这三种模式都有被使用，目前还没有明确的推荐方案产生。建议在公有云上的集群多考虑第一种模式，在私有云环境中由于维护额外的负载均衡器也是一项负担，建议考虑第二种或是第三种方案。

Kube-dns 高可用

严格来说 kube-dns 并不算是 Master 组件的一部分，因为它是可以跑在 Node 节点上，并用 Service 向集群内部提供服务的。但在实际环境中，由于默认配置只运行了一份 kube-dns 实例，在其升级或是所在节点当机时，会出现集群内部 dns 服务不可用的情况，严重时会影响到线上服务的正常运行。

为了避免故障，请将 kube-dns 的 replicas 值设为 2 或者更多，并用 anti-affinity 将他们部署在不同的 Node 节点上。这项操作比较容易被疏忽，直到出现故障时才发现原来是 kube-dns 只运行了一份实例导致的故障。

kube-controller-manager 与 kube-scheduler 高可用

这两项服务是 Master 节点的一部分，他们的高可用相对容易，仅需要运行多份实例即可。这些实例会通过向 apiserver 中的 Endpoint 加锁的方式来进行 leader election，当目前拿到 leader 的实例无法正常工作时，别的实例会拿到锁，变为新的 leader。

目前在多个 Master 节点上采用 static pod 模式部署这两项服务的方案比较常见，激进一点也可以采用 self-hosted 的模式，在 Kubernetes 之上用 DaemonSet 或者 Deployment 来部署。

网络插件

参考

静态路由

事先设置好路由器和主机中的路由表信息，网络性能最佳的方案，但不便于管理路由表。

flannel

Flannel 是 CoreOS 团队针对 Kubernetes 设计的一个网络规划服务，简单来说，它的功能是让集群中的不同节点主机创建的 Docker 容器都具有全集群唯一的虚拟 IP 地址。
在默认的 Docker 配置中，每个节点上的 Docker 服务会分别负责所在节点容器的 IP 分配。这样导致的一个问题是，不同节点上容器可能获得相同的内外 IP 地址。并使这些容器之间能够之间通过 IP 地址相互找到，也就是相互 ping 通。
Flannel 的设计目的就是为集群中的所有节点重新规划 IP 地址的使用规则，从而使得不同节点上的容器能够获得“同属一个内网”且”不重复的” IP 地址，并让属于不同节点上的容器能够直接通过内网 IP 通信。
Flannel 实质上是一种“覆盖网络（overlaynetwork）”，也就是将 TCP 数据包装在另一种网络包里面进行路由转发和通信，目前已经支持 UDP、VXLAN、host-gw、aws-vpc、GCE 和 Alloc 路由等数据转发方式，默认的节点间数据通信方式是 UDP 转发。

hostgw 模式

性能最高，原理非常简单，直接添加路由，将目的主机当做网关，直接路由原始封包。这正是 host-gw 的含义。所有的子网和主机的信息，都保存在 etcd 中，flanneld 只需要 watch 这些数据的变化，实时更新路由表就行了。核心是 IP 包在封装成桢的时候，使用路由表的“下一跳”设置上的 MAC 地址，这样可以经过二层网络到达目的宿主机。

例如，我们从 etcd 中监听到一个 Event Added 事件 subnet 为 10.1.15.0/24 被分配给主机 Public IP 192.168.0.100，hostgw 要做的工作就是在本主机上添加一条目的地址为 10.1.15.0/24，网关地址为 192.168.0.100，输出设备为上文中选择的集群间交互的网卡即可。对于 Event Removed 事件，只需删除对应的路由。

udp 模式

核心就是通过 TUN 设备 flannel0 实现（ TUN 设备是工作在三层的虚拟网络设备，功能是：在操作系统内核和用户应用程序之间传递 IP 包）相比两台宿主机直接通信，多出了 flanneld 的处理过程，这个过程，使用了 flannel0 这个 TUN 设备，仅在发出 IP 包的过程中就要经过了三次用户态到内核态的数据拷贝（ linux 的上下文切换代价比较大），所以性能非常差。

vxlan 模式

VXLAN，即 Virtual Extensible LAN（虚拟可扩展局域网），是 Linux 本身支持的一网种网络虚拟化技术。VXLAN 可以完全在内核态实现封装和解封装工作，从而通过“隧道”机制，构建出覆盖网络（Overlay Network）

VXLAN 的设计思想是：在现有的三层网络之上，“覆盖”一层虚拟的、由内核 VXLAN 模块负责维护的二层网络，使得连接在这个 VXLAN 二 nfcu 网络上的“主机”（虚拟机或容器都可以），可以像在同一个局域网（LAN）里那样自由通信。为了能够在二 nfcu 网络上打通“隧道”，VXLAN 会在宿主机上设置一个特殊的网络设备作为“隧道”的两端，叫 VTEP：VXLAN Tunnel End Point（虚拟隧道端点）

Calico

Calico 是一个纯 3 层的数据中心网络方案，而且无缝集成像 OpenStack 这种 IaaS 云架构，能够提供可控的 VM、容器、裸机之间的 IP 通信。Calico 不使用叠加网络比如 Flannel 和 Libnetwork 叠加网络驱动，它是一个纯三层的方法，使用虚拟路由代替虚拟交换，每一台虚拟路由通过 BGP 协议传播可达信息（路由）到剩余数据中心。
Calico 在每一个计算节点利用 Linux Kernel 实现了一个高效的 vRouter 来负责数据转发，而每个 vRouter 通过 BGP 协议负责把自己上运行的 workload 的路由信息像整个 Calico 网络内传播——小规模部署可以直接互联，大规模下可通过指定的 BGP route reflector 来完成。
Calico 节点组网可以直接利用数据中心的网络结构（无论是 L2 或者 L3），不需要额外的 NAT，隧道或者 Overlay Network 。
Calico 基于 iptables 还提供了丰富而灵活的网络 Policy，保证通过各个节点上的 ACLs 来提供 Workload 的多租户隔离、安全组以及其他可达性限制等功能。

NSX-T

主要适用于 vSphere 虚拟化平台，ESXi 虚拟化的不二之选。以下内容摘自官方文档适用于 Kubernetes 和 Cloud Foundry 的 NSX Container Plug-in - 安装和管理指南。

VMware NSX-T™ Data Center（以前称为 NSX-T）提供了一个敏捷式软件定义基础架构，用来构建云原生应用程序环境。专注于为具有异构端点环境和技术堆栈的新兴应用程序框架和架构提供网络、安全和自动化并简化操作。NSX-T Data Center 支持云原生应用程序、裸机工作负载、多管理程序环境、公有云和多个云。旨在由开发组织管理、操作和使用。NSX-T Data Center 允许 IT 和开发团队选择最适合其应用程序的技术。

NSX Container Plug-in(NCP) 提供 NSX-T Data Center 与容器协调器（如 Kubernetes）之间的集成以及 NSX-T Data Center 与基于容器的 PaaS（平台即服务）产品（如 OpenShift 和 Pivotal Cloud Foundry）之间的集成。NCP 的主要组件在容器中运行，并与 NSX Manager 和 Kubernetes 控制层面进行通信。NCP 调用 NSX API 以监控对容器和其他资源的更改以及管理网络资源，如容器的逻辑端口、交换机、路由器和安全组。NSX CNI 插件在每个 Kubernetes 节点上运行。它监控容器生命周期事件，将容器接口连接到客户机 vSwitch，并对客户机 vSwitch 进行编程以标记和转发容器接口和 vNIC 之间的容器流量。

功能特性

自动为 Kubernetes 群集创建 NSX-T Data Center 逻辑拓扑，并为每个 Kubernetes 命名空间创建一个单独的逻辑网络。
将 Kubernetes pod 连接到逻辑网络，并分配 IP 和 MAC 地址。
支持网络地址转换 (NAT) 并为每个 Kubernetes 命名空间分配一个单独的 SNAT IP。
使用 NSX-T Data Center 分布式防火墙实现 Kubernetes 网络策略。
支持输入和输出网络策略。
支持网络策略中的 IPBlock 选择器。
为网络策略指定标签选择器时，支持 matchLabels 和 matchExpression。
支持在其他命名空间中选择 pod。
实现 ClusterIP 类型的 Kubernetes 服务和 LoadBalancer 类型的服务。
使用 NSX-T 第 7 层负载平衡器实现 Kubernetes Ingress。
通过 TLS Edge 终止支持 HTTP Ingress 和 HTTPS Ingress。
支持 Ingress 默认后端配置。
支持 Ingress URI 重写。
在 NSX-T Data Center 逻辑交换机端口上为命名空间、pod 名称和 pod 标签创建标记，并允许管理员根据标记定义 NSX-T 安全组和策略。

持久化存储方案

参考

NFS

vSphere vSAN

Gluster

Ceph

Rook

日志方案

采集方式：

在宿主机上实现日志采集

在容器镜像中添加采集 Agent

基于 Sidecar 日志采集方式

ELK 方案

Elasticsearch

Logstash

Kibana

EFK 方案

和 ELK 不同的是 EFK 方案中使用 Fluentd 来采集日志。

Fluentd

监控方案

Cadvisor+InfluxDB+Grafana

Heapster+InfluxDB+Grafana

Promethus+metrics+Grafana

采集	cAdvisor、Heapster,、collectd,、Statsd、 Tcollector、 Scout
存储	InfluxDb、OpenTSDB、 Elasticsearch
展示	Graphite、Grafana、facette、 Cacti、Ganglia、DataDog
告警	Nagios、prometheus、Icinga、Zabbix

Grafana

开源 DashBoard，后端支持多种数据库，如：Influxdb、Prometheus…，插件也比较多，功能强大。非常适合用于做展示。

InfluxDB

开源分布式时间时序、事件和指标数据库，使用 Go 语言编写，性能高效，无需外部依赖，其设计目标是实现分布式和水平伸缩扩展。

特性

使用类 SQL 语句；
提供 min, max, sum, count, mean 等聚合函数；
采用 Schemaless ，列存储，压缩率高，可以存储任意数量的列；
可以将秒级监控在后台转换为分钟级，减小存储空间 (Continuous Queries)；
Built-in Explorer 自带管理工具，默认不打开，需要在配置文件中配置；
Native HTTP API，采用内置 HTTP 服务 (Protobuf API 暂时不提供)。
支持 Regular Timeseries 以及 Irregular Timeseries，前者是指时间间隔固定，后者指不固定，例如报警、入侵事件等；

cAdvisor

来自 Google 的容器监控工具，也是 Kubelet 内置的容器资源收集工具。它会自动收集本机容器 CPU、内存、网络和文件系统的资源占用情况，并对外提供 cAdvisor 原生的 API。

Heapster

由于 cAdvisor 只提供了单机的容器资源占用情况，而 Heapster 则提供了整个集群的资源监控（kubernetes 1.11 之前，hpa 都是从 heapster 获取数据），并支持持久化数据存储到 InfluxDB

kube-state-metrics

在这里作为 prometheus 的一个 exporter 来使用，提供 deployment、daemonset、cronjob 等服务的监控数据，由 kubernestes 官方提供，与 prometheus 紧密结合。

Promethues

在 Kubernetes 社区中，很多人认为 Prometheus 是容器场景中监控的第一方案，成为容器监控标准的制定者。其提供强大的数据采集、数据存储、数据展示、告警等，天生完美支持 kubernetes，CNCF 基金会的第二个成员，第一个是 Kubernetes 。而且 Prometheus 里面很多思想都来源于 Google 内部的监控系统 Borgmon，其方案相当成熟。

特性

多维数据模型（有 metric 名称和键值对确定的时间序列）
灵活的查询语言
不依赖分布式存储
通过 pull 方式采集时间序列，通过 http 协议传输
支持通过中介网关的 push 时间序列的方式
监控数据通过服务或者静态配置来发现
支持多维度可视化分析和 dashboard 等

监控层面

基础设施层：监控各个主机服务器资源(包括 Kubernetes 的 Node 和非 Kubernetes 的 Node)，如 CPU,内存,网络吞吐和带宽占用,磁盘 I/O 和磁盘使用等指标。
中间件层：监控独立部署于 Kubernetes 集群之外的中间件，例如：MySQL、Redis、RabbitMQ、ElasticSearch、Nginx 等。
Kubernetes 集群：监控 Kubernetes 集群本身的关键指标
Kubernetes 集群上部署的应用：监控部署在 Kubernetes 集群上的应用

组件

prometheus-server：数据存储以及监控数据聚合
prometheus-config-reloader：动态更新 prometheus 配置
rules-configmap-reloader：动态更新 prometheus 报警配置
alert manager：报警组件
node-exporter：节点资源信息采集组件
kube-state-metrics：动态发现 endpoint，三方监控的核心组件
prometheus-operator：prometheus 配置的 operator
grafana：数据展现

CI/CD 方案

参考

Jenkins

Gitlab CI

Drone

镜像 registry

镜像仓库负责存储和发布应用的镜像部署版本，在功能上并不复杂，但由于安全性的要求。用于生产发布的镜像版本必须通过严格的测试阶段，以及严密的安全检查步骤，因此建议对生产环境运行专用的生产镜像仓库；同时，在持续集成越来越普遍的情况下，为了保证开发和测试的方便，我们需要测试镜像仓库。建议生产镜像库和测试镜像库在物理上分开、网络上的连通通过防火墙策略做限制（只开放必须的端口用于镜像同步）。

在使用规则上，测试镜像仓库允许随时的镜像上传和更新，通常都会对接持续集成系统；而对于生产镜像仓库，为了保证镜像来源的安全、可控，建议限制为只能从测试镜像同步，规定只有在测试镜像仓库中标记为完成测试、经过安全检查的镜像，由有相应权限的账号，在经过必要的审批或者满足一定规则的情况下，从测试镜像仓库中把镜像同步到生产镜像仓库。一旦镜像进入生产镜像仓库，就被当做正式的生产发布版本，接下来就按照现有的生产发布和变更流程，在指定的变更窗口，从生产镜像库中拉取镜像进行部署，这样做也很好地满足安全监管要求。

harbor

Harbor 是一个用于存储和分发 Docker 镜像的企业级 Registry 服务器。通过添加一些企业必需的功能特性，例如安全、标识和管理等，扩展了开源 Docker Distribution。作为一个企业级私有 Registry 服务器，Harbor 提供了更好的性能和安全。提升用户使用 Registry 构建和运行环境传输镜像的效率。Harbor 支持安装在多个 Registry 节点的镜像资源复制，镜像全部保存在私有 Registry 中，确保数据和知识产权在公司内部网络中管控。另外，Harbor 也提供了高级的安全特性，诸如用户管理，访问控制和活动审计等。

特性

镜像注册中心:支持容器镜像和 Helm。为镜像提供一个注册服务和编排平台。
基于角色的访问控制: 用户可以创建不同的‘项目‘，并且拥有不同权限。
镜像复制:Harbor 会在复制遇到任何错误时自动重试。适用于负载均衡、高可用性、多数据中心、混合和多云场景
漏洞扫描：Harbor 定期扫描镜像并警告用户存在漏洞。
AD/LDAP 支持:Harbor 可以集成企业内部已有的 AD/LDAP，用于鉴权认证管理。
OIDC 支持:一种基于 OAuth2 的协议
垃圾回收:镜像被删除的时候可以自动垃圾回收。并且可以定时设置垃圾清理。
友好的界面操作:用户可以轻松方便的镜像管理，支持中英文等多语言。
审计:跟踪用户对镜像的操作历史
RESTful API：大多数管理操作的 RESTful Api，易于与外部系统集成。嵌入式 Swagger UI 可用于探索和测试 API（管理界面左下角的‘API 控制中心)
轻松部署：提供联机和脱机安装程序。此外，Helm Chart 用于在 Kubernetes 上部署 Harbor。

quay

在 11 月份红帽宣布开源 quay

特性

镜像仓库高可用和灾备：数据中心内部 HA，在数据中心之间同步镜像
支持 CI：当开发人员提交代码以后，自动触发代码构建。
支持安全扫描：自动扫描容器镜像，以查找已知的安全漏洞。
企业认证：集成到现有的身份基础架构：LDAP，Keystone 等
灵活的存储后端：将容器存储在 Amazon S3，OpenStack Swift，Google 云端存储中，或直接存储到磁盘。
记录和审计审计对于 CI 管道中的所有内容都至关重要。跟踪通过 API 和 UI 执行的操作。

Quay 的企业级功能

异地复制
高可用性和可扩展性
安全扫描
自动构建触发器
时间机器 image 回滚（基于 build 版本的回退）
细粒度的访问控制
自动连续垃圾收集，无需停机
与多个存储后端集成（ceph 等）
加密的 CLI 密码
洪流分布
容器和应用程序注册
与 Quay.io 保持一致的 UI 和代码库

镜像扫描：

quay 的镜像安全扫描基于 clair：Clair 项目是一个开源项目，使 Quay Security Scanner 能够检测 Quay Enterprise 中所有图像的漏洞，并在发现这些问题时通知开发人员。

自动构建：

通过集成到 GitHub，Bitbucket 等，自动构建存储库推送操作上的映像。随着代码（GitHub，Bitbucket，GitLab 和 Git）中的推送操作发生，Quay 将自动构建新版本的应用程序

image 回滚:

Time Machine 提供图像回滚，查看标签历史记录，快速轻松地切换图像构建。

查看 image build 历史记录，并可以选择某个版本的构建进行回退;

细颗粒度的 RBAC 配置:

支持许多身份提供商：LDAP，OAuth，OpenStack Keystone 等。

事件和使用日志：

针对存储库捕获所有事件
Pull, push events
权限更改
build 事件
标签更改

自动压缩 image：

将多个 docker layer 压缩成一个，以创建一个 layer 更少的 image：

自动进行 K8S 应用部署：

$ helm registry install quay.io/jzelinskie/nginx

事件通知

发布电子邮件、quay 通知、webhook 发布、flowdock，hipchat，基于 Quay Enterprise 内部各种事件的通知

集群优化

网络 MTU

内核版本

参考文档

service 实现形式

性能对比参考文章 kube-proxy 模式对比：iptables 还是 IPVS

kube-proxy 是 Kubernetes 中的关键组件。他的角色就是在服务（ClusterIP 和 NodePort）和其后端 Pod 之间进行负载均衡。kube-proxy 有三种运行模式，每种都有不同的实现技术：userspace、iptables 或者 IPVS。

userspace 模式非常陈旧、缓慢，已经不推荐使用。但是 iptables 和 IPVS 该如何选择呢？本文中我们会对这两种模式进行比较，看看他们在真正的微服务上下文中的表现，并解释在特定情况下的选择方法。

性能对比

iptables 的连接处理算法复杂度是 O(n)，而 IPVS 模式是 O(1)，但是在微服务环境中，其具体表现如何呢？

在多数场景中，有两个关键属性需要关注：

响应时间：一个微服务向另一个微服务发起调用时，第一个微服务发送请求，并从第二个微服务中得到响应，中间消耗了多少时间？
CPU 消耗：运行微服务的过程中，总体 CPU 使用情况如何？包括用户和核心空间的 CPU 使用，包含所有用于支持微服务的进程（也包括 kube-proxy）。

为了说明问题，我们运行一个微服务作为客户端，这个微服务以 Pod 的形式运行在一个独立的节点上，每秒钟发出 1000 个请求，请求的目标是一个 Kubernetes 服务，这个服务由 10 个 Pod 作为后端，运行在其它的节点上。接下来我们在客户端节点上进行了测量，包括 iptables 以及 IPVS 模式，运行了数量不等的 Kubernetes 服务，每个服务都有 10 个 Pod，最大有 10,000 个服务（也就是 100,000 个 Pod）。我们用 golang 编写了一个简单的测试工具作为客户端，用标准的 NGINX 作为后端服务。

响应时间

响应时间很重要，有助于我们理解连接和请求的差异。典型情况下，多数微服务都会使用持久或者 keepalive 连接，这意味着每个连接都会被多个请求复用，而不是每个请求一次连接。这很重要，因为多数连接的新建过程都需要完成三次 TCP 握手的过程，这需要消耗时间，也需要在 Linux 网络栈中进行更多操作，也就会消耗更多 CPU 和时间。

这张图展示了两个关键点：

iptables 和 IPVS 的平均响应时间在 1000 个服务（10000 个 Pod）以上时，会开始观察到差异。
只有在每次请求都发起新连接的情况下，两种模式的差异才比较明显。

不管是 iptables 还是 IPVS，kube-proxy 的响应时间开销都是和建立连接的数量相关的，而不是数据包或者请求数量，这是因为 Linux 使用了 Conntrack，能够高效地将数据包和现存连接关联起来。如果数据包能够被 Conntrack 成功匹配，那就不需要通过 kube-proxy 的 iptables 或 IPVS 规则来推算去向。Linux conntrack 非常棒！（绝大多数时候）

值得注意的是，例子中的服务端微服务使用 NGINX 提供一个静态小页面。多数微服务要做更多操作，因此会产生更高的响应时间，也就是 kube-proxy 处理过程在总体时间中的占比会减少。

还有个需要解释的古怪问题：既然 IPVS 的连接过程复杂度是 O(1)，为什么在 10,000 服务的情况下，非 Keepalive 的响应时间还是提高了？我们需要深入挖掘更多内容才能解释这一问题，但是其中一个因素就是因为上升的 CPU 用量拖慢了整个系统。这就是下一个主题需要探究的内容。

CPU 用量

为了描述 CPU 用量，下图关注的是最差情况：不使用持久/keepalive 连接的情况下，kube-proxy 会有最大的处理开销。

上图说明了两件事：

在超过 1000 个服务（也就是 10,000 个 Pod）的情况下，CPU 用量差异才开始明显。
在一万个服务的情况下（十万个后端 Pod），iptables 模式增长了 0.35 个核心的占用，而 IPVS 模式仅增长了 8%。

有两个主要因素造成 CPU 用量增长：

第一个因素是，缺省情况下 kube-proxy 每 30 秒会用所有服务对内核重新编程。这也解释了为什么 IPVS 模式下，新建连接的 O(1) 复杂度也仍然会产生更多的 CPU 占用。另外，如果是旧版本内核，重新编程 iptables 的 API 会更慢。所以如果你用的内核较旧，iptables 模式可能会占用更多的 CPU。

另一个因素是，kube-proxy 使用 IPVS 或者 iptables 处理新连接的消耗。对 iptables 来说，通常是 O(n) 的复杂度。在存在大量服务的情况下，会出现显著的 CPU 占用升高。例如在 10,000 服务（100,000 个后端 Pod）的情况下，iptables 会为每个请求的每个连接处理大约 20000 条规则。如果使用 NINGX 缺省每连接 100 请求的 keepalive 设置，kube-proxy 的 iptables 规则执行次数会减少为 1%，会把 iptables 的 CPU 消耗降低到和 IPVS 类似的水平。

客户端微服务会简单的丢弃响应内容。真实世界中自然会进行更多处理，也会造成更多的 CPU 消耗，但是不会影响 CPU 消耗随服务数量增长的事实。

结论

在超过 1000 服务的规模下，kube-proxy 的 IPVS 模式会有更好的性能表现。虽然可能有多种不同情况，但是通常来说，让微服务使用持久连接、运行现代内核，也能取得较好的效果。如果运行的内核较旧，或者无法使用持久连接，那么 IPVS 模式可能是个更好的选择。

抛开性能问题不谈，IPVS 模式还有个好处就是具有更多的负载均衡算法可供选择。

如果你还不确定 IPVS 是否合适，那就继续使用 iptables 模式好了。这种传统模式有大量的生产案例支撑，他是一个不完美的缺省选项。

补充：Calico 和 kube-proxy 的 iptables 比较

本文中我们看到，kube-proxy 中的 iptables 用法在大规模集群中可能会产生性能问题。有人问我 Calico 为什么没有类似的问题。答案是 Calico 中 kube-proxy 的用法是不同的。kube-proxy 使用了一个很长的规则链条，链条长度会随着集群规模而增长，Calico 使用的是一个很短的优化过的规则链，经由 ipsets 的加持，也具备了 O(1) 复杂度的查询能力。

下图证明了这一观点，其中展示了每次连接过程中，kube-proxy 和 Calico 中 iptables 规则数量的平均值。这里假设集群中的节点平均有 30 个 Pod，每个 Pod 具有 3 个网络规则。

即使是使用 10,000 个服务和 100,000 个 Pod 的情况下，Calico 每连接执行的 iptables 规则也只是和 kube-proxy 在 20 服务 200 个 Pod 的情况基本一致。

安全加固

简介：CIS Kubernetes 安全基准指南

33 个 Kubernetes 安全工具

工具

TUF

TUF 是一项用于保护软件更新系统的开源安全技术，也是从云原生计算基金会毕业的第一个以规范与安全性为重点的项目。与此同时，TUF 还是首个源自高校的 CNCF 毕业项目。

kube-score

kube-score 是 K8s 对象静态检查工具，通过分析 K8s 对象的 Yaml 文件做一些推荐，以提升可靠性和安全性。

Ingress

常见 ingress 对比列表

全文	Kubernetes Ingress	NGINX Ingress	Traefik	HAproxy	Contour
Protocol	http/https, http2, grpc, tcp/udp (partial)	http/https, http2, grpc, tcp/udp	http/https, http2 (h2c), grpc, tcp, tcp+tls	http/https, http2, grpc, tcp, tcp+tls	http/https, http2, grpc, tcp/udp, tcp+tls
base	nginx	nginx/nginx plus	traefik	haproxy	envoy
Traffic routing	host, path (with regex)	host, path	host (regex), path (regex), headers (regex), query, path prefix, method	host, path	host, path
Namespace limitations	All cluster or specified namespaces	All cluster or specified namespaces	All cluster or specified namespaces	All cluster or specified namespaces	All cluster or specified namespaces
Traffic distribution	canary, a/b (cookie balancing)	-	canary, blue-green, shadowing	blue-green, shadowing	canary, blue-green
Upstream probes	retry, timeouts	retry, active health checks (based on http probe for pod)	retry, timeouts, active, circuit breaker	check-uri, check-address, check-port	timeouts, active
负载均衡	round-robin, sticky sessions, least-conn, ip-hash, ewma	round-robin, least-conn, least-time, random, sticky sessions	weighted-round-robin, dynamic-round-robin, sticky sessions	round-robin, static-rr, leastconn, first, source, uri, url_param, header, sticky sessions	round-robin, sticky sessions, weighted-least-request, ring hash, maglev, random
Authentication	Basic, Client cert, external Basic, external OAuth	Basic	Basic, auth-url, auth-tls, external auth	Basic, OAuth, Auth TLS	-
Paid subscription	-	+	+	+	-
GUI	-	+	+	-	-
JWT validation	-	+	-	+	-
Basic DDoS protection	rate limit, limit conn, liimt rps, limit rpm, limit-rate-after, limit-whitelist	rate limit, rate-limit-burst	max-conn, rate limit, ip whitelist	limit-rps, limit-connections, limit-whitelist	max-conn, max-request
Requests tracing	+	-	+	-	-
Config customization	+	+	+	+	-
WAF	lua-resty-waf, ModSecurity	+	-	ModSecurity	-

Ingress NGINX

Kubernetes 官方维护的方案

Traefik

是一个用 Golang 开发的轻量级的 http 反向代理和负载均衡器，虽然相比于 nginx ，它是后起之秀，但是它天然拥抱 Kubernetes，直接与集群 K8s 的 api Server 通信，反应非常迅速，实时感知集群中 ingress 定义的路由规则集合和后端 Service、Pod 的变化，自动热更新 Traefik 后端配置，根本不用创建 ingress controller 对象，同时还提供了友好的控制面板和监控界面，不仅可以方便地查看 Traefik 根据 ingress 生成的路由配置信息，还可以查看统计的一些性能指标数据，如：总响应时间、平均响应时间、不同的响应码返回的总次数等。

Contour

Contour 不仅基于 Envoy，而且还与该流行代理的作者共同开发。通过特殊的 CRD（称为 Ingress Route 的新 API ）管理 Ingress 资源的能力是其特殊功能。对于具有多个开发团队并发使用一个集群的组织，这有助于保护相邻环境中的流量并保护它们免受 Ingress 资源更改时产生的错误的影响。

它还提供了一组扩展的平衡算法（镜像，自动重复，限制请求率等等），详细的流量和故障监控。对于某些人来说，也许缺少对粘性会议的支持将是一个严重的缺陷（朝这个方向的持续努力已经走了很长一段路）。

F5 BIG-IP Controller

F5 所开发的控制器，它能够让管理员通过 CLI 或 API 让 Kubernetes 与 OpenShift 管理 F5 BIG-IP 设备。

性能测试

高可用测试

应用高可用

使用工具随机杀死集群中一半的 Pod ，来测试工作负载的可用性。

网络性能测试

End-to-End Testing in Kubernetes

存储性能测试

周边

dashboard

Octant

Kuboard

Kustomize

特性：

功能简单清晰，kubectl 直接支持。
不考虑派生，仅作为应用的 YAML 组织方式也很有帮助。
也有自己的插件系统。例如可以用简单的 YAML 定义，使用文件生成 Configmap/Secret。

helm

特性：

强大的生命周期管理：有 Tiller 的帮助，可以实现对应用程序实例（Release）的查询、安装、卸载、升级、回滚等复杂操作。
严格的基础版本管控：Chart 是一种模板，Chart 的用户仅能通过对 values 的控制来定制应用的部署行为，模板中没有提供变量的位置，是无法在下游直接进行变更的。
方便的命令行：对于简单变量，可以在部署的同时直接指定内容，方便部署。
插件和工具：Helm 拥趸众多，提供了不少用于 CICD 或者其它方面辅助功能的插件和工具。

移除 Tiller 组件：只有 helm 这个客户端来和 kubernetes 集群进行交互操作。helm2 的交互流程： helm client –gRPC–> helm server (Tiller) –> kubernetes api (install chart)
Release name 可缩小至 Namespace 范围（意味着 release name 可重复）：helm2 中的 release name 是全局的，意味着即使安装某个 chart 到不同的 Namespace，release name 名字也不能一样。Chart Release 记录都和 Tiller 服务一起，在一个 Namespace 中。现在由于移除了 Tiller 组件，每个 chart 的 Release 记录与它部署到哪个 namespace 一样，存在同一个 Namespace 中。这样就可以在不同 Namespace 中使用同一个 Release name。
默认关闭随机生成 release name，需要显示启用选项 --generate-name
移除 helm serve 提供本地 repository 功能
将 requirements.yaml 的内容移到 Chart.yaml 文件中
支持 helm push 到远端 chart repository，支持登陆认证
支持 Chart Library（keeping charts DRY.）
简化内置模版里面的对象
使用 JSONSchema 验证 chart 的 Values

Operator

Operator 是由 CoreOS 开发的，用来扩展 Kubernetes API，特定的应用程序控制器，它用来创建、配置和管理复杂的有状态应用，如数据库、缓存和监控系统。Operator 基于 Kubernetes 的资源和控制器概念之上构建，但同时又包含了应用程序特定的领域知识。创建 Operator 的关键是 CRD（自定义资源）的设计。

Kubernetes 1.7 版本以来就引入了自定义控制器的概念，该功能可以让开发人员扩展添加新功能，更新现有的功能，并且可以自动执行一些管理任务，这些自定义的控制器就像 Kubernetes 原生的组件一样，Operator 直接使用 Kubernetes API 进行开发，也就是说他们可以根据这些控制器内部编写的自定义规则来监控集群、更改 Pods/Services、对正在运行的应用进行扩缩容。

Operator Framework 同样也是 CoreOS 开源的一个用于快速开发 Operator 的工具包，该框架包含两个主要的部分：

Operator SDK: 无需了解复杂的 Kubernetes API 特性，即可让你根据你自己的专业知识构建一个 Operator 应用。
Operator Lifecycle Manager OLM: 帮助你安装、更新和管理跨集群的运行中的所有 Operator（以及他们的相关服务）

工作流程：

使用 SDK 创建一个新的 Operator 项目
通过添加自定义资源（CRD）定义新的资源 API
指定使用 SDK API 来 watch 的资源
定义 Operator 的协调（reconcile）逻辑
使用 Operator SDK 构建并生成 Operator 部署清单文件

kubebuilder

目前扩展 Kubernetes 的 API 的方式有创建 CRD、使用 Operator SDK 等方式，都需要写很多的样本文件（boilerplate），使用起来十分麻烦。为了能够更方便构建 Kubernetes API 和工具，就需要一款能够事半功倍的工具，与其他 Kubernetes API 扩展方案相比，kubebuilder 更加简单易用，并获得了社区的广泛支持。

通过 Operator 的方案，可以对 Kubernetes 的功能进行友好地扩展。Operatpr = CRD + Controller。首先通过 yaml 定义，生成 CRD ，然后 Controller 不断地监听 etcd 中的数据，执行相应动作。开发 Operator 时，有很多繁琐且重复的事情。KubeBuilder 可以帮助我们快速生成骨架代码，开发一个 Kubernetes 的扩展功能，更多介绍可以参考文档：Kubernetes 复杂有状态应用管理框架 – Operator

工作流程：

创建一个新的工程目录
创建一个或多个资源 API CRD 然后将字段添加到资源
在控制器中实现协调循环（reconcile loop），watch 额外的资源
在集群中运行测试（自动安装 CRD 并自动启动控制器）
更新引导集成测试测试新字段和业务逻辑
使用用户提供的 Dockerfile 构建和发布容器