关于linux:Kubernetes-前世今生-附学习思维导图

尽管 Docker 曾经很弱小了，然而在理论应用上还是有诸多不便，比方集群治理、资源调度、文件治理等等。那么在这样一个百花齐放的容器时代涌现出了很多解决方案，比方 Mesos、Swarm、Kubernetes 等等，其中谷歌开源的 Kubernetes 是作为老大哥的存在。

Kubernetes 倒退经验

历史总是不尽的雷同，好的总会取代坏的。

Kubernetes 是希腊语『舵手』的意思，它最开始由 Google 的几位软件工程师创建，深受公司外部 Borg 和 Omega 我的项目的影响，很多设计都是从 Borg 中借鉴的，同时也对 Borg 的缺点进行了改良，Kubernetes 目前是 CNCF 的我的项目并且是很多公司治理分布式系统的解决方案。其中比拟有意思的一点是，Kubernetes 的简写称为 k8s。即该单词 k 和 s 两头刚好是 8 个字母组成，所以是一种单词的简写模式。相似于，咱们在我的项目中应用的国际化 (internationalization) 叫做 i18n 是一样成果。

建于 Docker 之上的 Kubernetes 能够构建一个容器的调度服务，其目标是让用户透过 Kubernetes 集群来进行云端容器集群的治理，而无需用户进行简单的设置工作，零碎会主动选取适合的工作节点来执行具体的容器集群调度解决工作。

其外围概念是 Container Pod。一个 Pod 由一组工作于同一物理工作节点的容器形成。这些组容器领有雷同的网络命名空间、IP 以及存储配额，也能够依据理论状况对每一个 Pod 进行端口映射。此外，Kubernetes 工作节点会由主零碎进行治理，节点蕴含了可能运行 Docker 容器所用到的服务。

咱们能够看到多种服务形式

• 阿里云 => Infrastructure as a service

• 新浪云 => Platform as a service

• Office365 => Software as a service

作为编排工具，从社区的年龄来讲，Kubernetes 不占优势。毕竟 Kubernetes 才三岁而已，而 Apache 推出的 Mesos 曾经有 7 年之久。Docker Swarm 尽管是比 Kubernetes 更年老，然而它的背地是来自于 Docker 官网容器核心的全方位反对。然而，因为是谷歌开源进去的，并且领有十多年的容器化的教训，所以还是有很多人在应用，并且会变成当前整个行业的次要支柱。

Kubernetes 解决的外围问题

• 服务发现和负载平衡

• Kubernetes 能够应用 DNS 名称或本人的 IP 地址公开容器，如果到容器的流量很大，Kubernetes 能够负载平衡并调配网络流量，从而使部署稳固。

• 存储编排

• Kubernetes 容许您主动挂载您抉择的存储系统，例如本地存储、公共云提供商等。

• 主动部署和回滚

• 您能够应用 Kubernetes 形容已部署容器的所需状态，它能够以受控的速率将理论状态更改为所需状态。例如，您能够自动化 Kubernetes 来为您的部署创立新容器，删除现有容器并将它们的所有资源用于新容器。

• 主动二进制打包

• Kubernetes 容许您指定每个容器所需 CPU 和内存（RAM）。当容器指定了资源申请时，Kubernetes 能够做出更好的决策来治理容器的资源。

• 自我修复

• Kubernetes 重新启动失败的容器、替换容器、杀死不响应用户定义的运行状况查看的容器，并且在筹备好服务之前不将其通告给客户端。

• 密钥与配置管理

• Kubernetes 容许您存储和治理敏感信息，例如明码、OAuth 令牌和 ssh 密钥。您能够在不重建容器镜像的状况下部署和更新密钥和应用程序配置，也无需在堆栈配置中裸露密钥。

Kubernetes 的呈现不仅主宰了容器编排的市场，更扭转了过来的运维形式，不仅将开发与运维之间边界变得更加含糊，而且让 DevOps 这一角色变得更加清晰，每一个软件工程师都能够通过 Kubernetes 来定义服务之间的拓扑关系、线上的节点个数、资源使用量并且可能疾速实现程度扩容、蓝绿部署等在过来简单的运维操作。

性能比照

当今三大支流调度零碎的比拟与剖析

• 比照总结

• Apache Mesos

Apache Mesos 是一个分布式系统内核的开源集群管理器，Apache Mesos 的呈现要远早于 Docker Swarm 和 Kubernetes。再加上 Marathon 这个基于容器的应用程序的编排框架，它为 Docker Swarm 和 Kubernetes 提供了一个无效的代替计划。Mesos 同时能够应用其余框架来同时反对容器化和非容器化的工作负载。

Mesos 可能在同样的集群机器上运行多种分布式系统类型，能够更加动静高效的共享资源。而且 Messos 也提供服务失败查看，服务公布，服务跟踪，服务监控，资源管理和资源共享。Messos 能够扩大伸缩到数千个节点。如果你领有很多的服务器而且想构建一个大的集群的时候，Mesos 就派上用场了。很多的现代化可扩展性的数据处理利用都能够在 Mesos 上运行，包含大数据框架 Hadoop、Kafka、Spark。

然而大而全，往往就是对应的简单和艰难，这一点体现在 Messos 上是完全正确，与 Docker 和 Docker Swarm 应用同一种 API 不同的，Mesos 和 Marathon 都有本人的 API，这使得它们比其余编排零碎更加的简单。Apache Mesos 是混合环境的完满编配工具，因为它蕴含容器和非容器的利用，尽管 Messos 很稳固，然而它的使用户疾速学习利用变得更加艰难，这也是在利用和部署场景下难于推广的起因之一。

• Docker Swarm

Docker Swarm 是 Docker 公司的容器编排零碎，应用的是规范 Docker API 接口，容器应用命令和 docker 命令是一套，简略不便。Docker Swarm 根本架构是也是简略间接，每个主机运行一个 Docker Swarm 代理，一个主机运行一个 Docker Swarm 管理者，这个管理者负责指挥和调度这些主机上的容器，Docker Swarm 以高可用性模式运行，Docker Swarm 中的一个节点充当其余节点的管理器，包含调度程序和服务发现组件的容器。

Docker Swarm 的长处和毛病都是应用规范的 Docker 接口，因为应用简略，容易集成到现有零碎，所以在反对简单的调度零碎时候就会比拟艰难了，特地是在定制的接口中实现的调度。这兴许就是成也在 Docker，败也在 Docker 的起因所在。

• Kubernetes

Kubernetes 作为一个容器集群管理系统，用于治理云平台中多个主机上的容器利用，Kubernetes 的指标是让部署容器化的利用变得简略且高效，所以 Kubernetes 提供了利用部署，布局，更新，保护的一整套残缺的机制。

Kubernetes 没有固定要求容器的格局，然而 Kubernetes 应用它本人的 API 和命令行接口来进行容器编排。除了 Docker 容器之外，Kubernetes 还反对其余多种容器，如 rkt、CoreOS 等。Kubernetes 是自成体系的管理工具，能够实现容器调度，资源管理，服务发现，健康检查，主动伸缩，更新降级等，也能够在利用模版配置中指定正本数量，服务要求（IO 优先；性能优先等），资源应用区间，标签（Labels 等）来匹配特定要求达到预期状态等，这些特色便足以驯服开发者，再加上 Kubernetes 有一个十分沉闷的社区。它为用户提供了更多的抉择以不便用户扩大编排容器来满足他们的需要。然而因为 Kubernetes 应用了本人的 API 接口，所以命令零碎是另外一套零碎，这也是 kubernetes 门槛比拟高的起因所在。

大部分的应用程序咱们在部署的时候都会适当的增加监控，对于运行载体容器则更应该如此。kubernetes 提供了 liveness probes 来查看咱们的应用程序，它是由节点上的 kubelet 定期执行的。

常识图谱

次要介绍学习一些什么常识

软件架构

传统的客户端服务端架构

• 架构阐明

Kubernetes 遵循十分传统的客户端 / 服务端的架构模式，客户端能够通过 RESTful 接口或者间接应用 kubectl 与 Kubernetes 集群进行通信，这两者在实际上并没有太多的区别，后者也只是对 Kubernetes 提供的 RESTful API 进行封装并提供进去。每一个 Kubernetes 集群都是由一组 Master 节点和一系列的 Worker 节点组成，其中 Master 节点次要负责存储集群的状态并为 Kubernetes 对象调配和调度资源。

• 主节点服务 – Master 架构

作为治理集群状态的 Master 节点，它次要负责接管客户端的申请，安顿容器的执行并且运行管制循环，将集群的状态向指标状态进行迁徙。Master 节点外部由上面三个组件形成：

API Server: 负责解决来自用户的申请，其次要作用就是对外提供 RESTful 的接口，包含用于查看集群状态的读申请以及扭转集群状态的写申请，也是惟一一个与 etcd 集群通信的组件。

etcd: 是兼具一致性和高可用性的键值数据库，能够作为保留 Kubernetes 所有集群数据的后盾数据库。

Scheduler: 主节点上的组件，该组件监督那些新创建的未指定运行节点的 Pod，并抉择节点让 Pod 在下面运行。调度决策思考的因素包含单个 Pod 和 Pod 汇合的资源需要、硬件 / 软件 / 策略束缚、亲和性和反亲和性标准、数据地位、工作负载间的烦扰和最初时限。

controller-manager: 在主节点上运行控制器的组件，从逻辑上讲，每个控制器都是一个独自的过程，然而为了升高复杂性，它们都被编译到同一个可执行文件，并在一个过程中运行。这些控制器包含：节点控制器(负责在节点呈现故障时进行告诉和响应)、正本控制器(负责为零碎中的每个正本控制器对象保护正确数量的 Pod)、端点控制器(填充端点 Endpoints 对象，即退出 Service 与 Pod))、服务帐户和令牌控制器(为新的命名空间创立默认帐户和 API 拜访令牌)。

• 工作节点 – Node 架构

其余的 Worker 节点实现就绝对比较简单了，它次要由 kubelet 和 kube-proxy 两局部组成。

kubelet: 是工作节点执行操作的 agent，负责具体的容器生命周期治理，依据从数据库中获取的信息来治理容器，并上报 pod 运行状态等。

kube-proxy: 是一个简略的网络拜访代理，同时也是一个 Load Balancer。它负责将拜访到某个服务的申请具体调配给工作节点上同一类标签的 Pod。kube-proxy 本质就是通过操作防火墙规定 (iptables 或者 ipvs) 来实现 Pod 的映射。

Container Runtime: 容器运行环境是负责运行容器的软件，Kubernetes 反对多个容器运行环境: Docker、containerd、cri-o、rktlet 以及任何实现 Kubernetes CRI(容器运行环境接口)。

组件阐明

次要介绍对于 K8s 的一些基本概念

次要由以下几个外围组件组成：

• apiserver

• 所有服务拜访的惟一入口，提供认证、受权、访问控制、API 注册和发现等机制

• controller manager

• 负责保护集群的状态，比方正本冀望数量、故障检测、主动扩大、滚动更新等

• scheduler

• 负责资源的调度，依照预约的调度策略将 Pod 调度到相应的机器上

• etcd

• 键值对数据库，保留了整个集群的状态

• kubelet

• 负责保护容器的生命周期，同时也负责 Volume 和网络的治理

• kube-proxy

• 负责为 Service 提供 cluster 外部的服务发现和负载平衡

• Container runtime

• 负责镜像治理以及 Pod 和容器的真正运行

除了外围组件，还有一些举荐的插件：

• CoreDNS

• 能够为集群中的 SVC 创立一个域名 IP 的对应关系解析的 DNS 服务

• Dashboard

• 给 K8s 集群提供了一个 B/S 架构的拜访入口

• Ingress Controller
• 官网只可能实现四层的网络代理，而 Ingress 能够实现七层的代理
• Prometheus
• 给 K8s 集群提供资源监控的能力
• Federation

• 提供一个能够跨集群核心多 K8s 的对立治理性能，提供跨可用区的集群

作者: Escape
链接: https://www.escapelife.site/p…