Kubernetes系列之基础概念

小伙伴儿们，如果觉得文章干货满满，欢迎加入公众号【编程识堂】，更多干货等着你们来哦！

前言

通过我前面的文章Docker-Swarm,已经简单了解了容器集群化部署； 长期以来，Kubernetes 和 Docker Swarm被看做是vs的对手，在接下来的对比中，我们看一下它们 应该在何时被使用，以及怎么一起工作的。
目前主流的容器化集群部署方案主要有以下几种：

• Docker Compose：帮助在 同一个节点 上部署多个容器。

• Docker Swarm：多台机器上部署容器。开箱即用，快速部署容器。偏重容器部署

• K8s：社区活跃度高，组件丰富。微服务化，偏重应用的部署。

  Kubernetes和Docker Swarm不是竞争对手！ 两者都有各自的优缺点，可以根据你应用程序的需求来选择使用。(择优选用，相互协作) ，下面我先介绍下各自概念和优缺点：
  Docker是一种容器管理服务，它帮助开发人员设计应用程序，使用容器能更容易地创建、部署和运 行应用程序。Docker有一个用于集群容器的内置机制，称为“集群模式”（swarm mode）。使用集群模 式，你可以使用Docker引擎在多台机器上启动应用程序。
  Docker Swarm是Docker自己针对Docker容器的原生集群解决方案，它的优点是紧密集成到 Docker的生态系统中，并且使用自己的API。它监视跨服务器集群的容器数量，是创建集群docker应用 程序的最方便的方法，不需要额外的硬件。它为Dockerized应用程序提供了一个小型但有用的编排系统。

使用Docker Swarm的优点

更快的运行速度 以更快的速度运行： 当您使用虚拟环境时，您可能已经意识到它需要很长时间，并且包含了启动和 启动您 想要运行的应用程序的冗长过程。对于Docker Swarm来说，这不再是一个问题。Docker Swarm不需要启动一个完整的虚拟机，就可以让应用程序在虚拟和软件定义的环境中快速运行，并 有助于DevOps的实现。
快速简单的配置 提供简单快速的配置： Docker Swarm的一个主要优点是它简化了问题。Docker Swarm使用户可 以自己配置，将其放入代码中并轻松部署。由于Docker Swarm可以在各种环境中使用，因此需求 不受应用程序环境的约束。
确保程序独立（容器间低耦合） 确保应用程序是隔离的：Docker Swarm负责将每个容器与其他容器隔离，并拥有自己的资源。你 可以部署各种容器，以便在不同的堆栈中运行单独的应用程序。除此之外，Docker Swarm将在每 个应用程序在自己的容器上运行时清除应用程序的删除。如果不再需要应用程序，可以删除它的容 器。它不会在您的主机OS上留下任何临时文件或配置文件。
版本控制与组件重用 版本控制和组件重用：使用Docker Swarm，您可以跟踪容器的连续版本、检查差异或回滚到前面 的版本。容器重用来自前一层的组件，这使得它们非常轻量级。

使用Docker Swarm的缺点

跨平台支持效果差 Docker依赖于平台: Docker Swarm是一个为Linux设计的平台。虽然Docker支持Windows和Mac OS X，但它使用虚拟机在非linux平台上运行。设计为在Windows上的Docker容器中运行的应用程 序不能在Linux上运行，反之亦然。
不提供存储选项 Docker Swarm不提供将容器连接到存储的简便方法，比如不能存储服务配置文件，秘钥等数据，这是主要缺点之一。它的数 据量需要对主机和手动配置进行大量的改进。如果你想要Docker Swarm解决存储问题，也能办 到，但是方式并不高效，且这种方式对用户并不友好。
监控信息不足 Docker Swarm提供关于容器的基本信息，如果您正在寻找基本的监控解决方案，那么使 用Stats命令就足够了。如果您正在寻找先进的监控，那么Docker集群不是好的选择。虽然有像 CAdvisor这样的第三方工具可以提供更多的监控，但是使用Docker本身实时收集更多关于容器的 数据是不可行的。

为了避免这些不足，可以使用Kubernetes

当在多台机器上的多个容器中使用不同组件开发应用程序时，需要一个工具来管理和协调容器。这只有 在Kubernetes的帮助下才可行。
Kubernetes是一个用于在集群环境中管理容器化应用程序的开源系统。以正确的方式使用Kubernetes 可以帮助DevOps作为一个服务团队自动扩展应用程序，并在零停机的情况下进行更新 。

使用Kubernetes的优点

它的速度很快 在不停机的情况下持续部署新功能时，Kubernetes是一个完美的选择。 Kubernetes的目标是以恒定的正常运行时间更新应用程序。它的速度通过您每小时可以运送的许 多功能来衡量，同时保持可用的服务。
遵循不可变基础架构的原则: 在传统的方法中，如果多个更新出现错误，您没有任何关于部署了多少个更新以及发生错误的时间点的记录。在不可变的基础架构中，如果想要更新任何应用程序，需要使用新标记构建容器映像并部署它，用旧映像版本销毁旧容器。这样，你就会有一个记录，并了 解你做了什么，万一有什么错误;您可以轻松地回滚到前面的映像。
提供声明式配置 用户可以知道系统应该处于什么状态以避免错误。源代码控制、单元测试等传统 工具不能与命令式配置一起使用，但可以与声明式配置一起使用。
大规模部署和更新软件 由于Kubernetes具有不可变的声明性，因此扩展很容易。Kubernetes提 供了一些用于扩展目的的有用功能：

• 水平基础架构扩展：在单个服务器级别执行操作以应用水平扩展。可以毫不费力地添加或分离 atest服务器。
• 自动扩展：根据CPU资源或其他应用程序指标的使用情况，您可以更改正在运行的容器数
• 手动扩展：您可以通过命令或界面手动扩展正在运行的容器的数量
• 复制控制器：复制控制器确保集群在运行状态下具有指定数量的等效pod。如果存在太多 pod，则复制控制器可以删除额外的pod，反之亦然。
  处理应用程序的可用性 Kubernetes检查节点和容器的运行状况，并在由于错误导致的盒中崩溃 时提供自我修复和自动替换。此外，它在多个pod之间分配负载，以便在意外流量期间快速平衡资源。
  存储卷 在Kubernetes中，数据是在容器之间共享的，但是如果pod被杀死，则自动删除卷。此外，数据是远程存储的，因此如果将pod移动到另一个节点，数据将一直保留，直到用户删除它 。

使用Kubernetes的缺点

学习曲线陡峭 K8s是一种复杂的系统，需要花费一定的时间和精力来学习和掌握。
部署和维护成本高 K8s需要一定的硬件资源和人力资源来部署和维护，成本较高。
需要专业知识 K8s需要一定的专业知识和技能来操作和管理，不适合初学者使用。
安全性问题 K8s的安全性问题需要得到重视，否则可能会出现安全漏洞和攻击。

Docker和Kubernetes是不同的，但不是竞争对手

正如前面所讨论的，Kubernetes和Docker都在不同的级别上工作，但都可以一起使用。 Kubernetes可以集成Docker引擎来执行Docker容器的调度和执行。由于Docker和Kubernetes都是容 器编排器，所以它们都可以帮助管理容器的数量，还可以帮助DevOps实现。两者都可以自动化运行容 器化的基础架构中涉及的大部分任务，并且都是开源软件项目，由Apache License 2.0管理。除此之 外，两者都使用YAML格式的文件来控制工具如何编排容器集群。当两者同时使用时，Docker和 Kubernetes都是部署现代云架构的最佳工具。随着Docker Swarm的豁免，Kubernetes和Docker都相互补充。

Kubernetes或Docker：哪个是完美的选择？

如果使用Kubernetes： 您正在寻找成熟的部署和监控选项 您正在寻找快速可靠的响应时间 您正在寻求开发复杂的应用程序，并且需要高资源计算而不受限制 你有一个非常大的集群
如果使用Docker： 您希望在不花费太多时间进行配置和安装的情况下启动工具; 您正在寻找开发一个基本和标准的应用程序，它足够使用默认的docker镜像; 在不同的操作系统上测试和运行相同的应用程序对您来说不是问题; 您需要zdocker API经验和兼容性。

K8s基础组件

一个 Kubernetes 集群包含 集群由一组被称作节点的机器组成。这些节点上运行 Kubernetes 所管理的 容器化应用。集群具有至少一个工作节点和至少一个主节点。
工作节点托管作为应用程序组件的 Pod 。主节点管理集群中的工作节点和 Pod 。多个主节点用于为集 群提供故障转移和高可用性。
本文概述交付正常运行的 Kubernetes 集群所需的各种组件。 这张图表展示了包含所有相互关联组件的 Kubernetes 集群 。

1.1 控制平面组件（Control Plane Components）

1.1.1 kube-apiserver

• 整个集群的核心大脑，是集群的统一入口，无论是master节点还是node节点，所有组件都得通过kube-apiserver互相去转发，是所有组件的协调者；
• 提供集群管理的REST API接口，所有对象资源的增删改查都可以和监听操作交给kube-apiserver处理协调之后再交给etcd,比如校验包括认证授权，数据校验以及集群状态变更等 ；
• 其他模块通过API Server查询或修改数据，只有API Server才直接操作etcd ；

1.1.2 etcd

• etcd 是兼具一致性和高可用性的键值数据库，k和value存储，可以作为保存 Kubernetes 所有集群数据的后台数据库。
• kubernetes需要存储很多东西，像它本身的节点信息，组件信息，还有通过kubernetes运行
  的pod，deployment，service等等。都需要持久化。etcd就是它的数据中心。生产环境中为
  了保证数据中心的高可用和数据的一致性，一般会部署最少三个节点。
• 这里只部署一个节点在master。etcd也可以部署在kubernetes每一个节点。组成etcd集群。
• 如果已经有etcd外部的服务，kubernetes直接使用外部etcd服务。

1.1.3 kube-scheduler

kube-scheduler负责分配调度Pod到集群内的节点上，它监听kube-apiserver，查询还未分配Node的Pod，然后根据调度策略为这些Pod分配节点。 比如资源的公平性调度，将通信频繁的一个节点调度到另外一个节点；负载均衡情况的调度等等；

1.1.4 kube-controller-manager

负责整个集群的管理，确保集群中各种资源都处于一种期望的状态， 它通过apiserver监控整个集群的状态 ，当监控到某个资源或者容器处于不正常状态时，这个管理控制器会触发kube-scheduler 去调度资源；
这些控制器包括:

• 节点控制器（Node Controller）: 负责在节点出现故障时进行通知和响应
• 容器副本数控制器（ Replication Controller ）： 控制副本
• 任务控制器（Job controller）: 监测代表一次性任务的 Job 对象，然后创建 Pods 来运行这些任务直至完成
• 端点控制器（Endpoints Controller）: 填充端点(Endpoints)对象(即加入 Service 与 Pod)
• 服务帐户和令牌控制器（Service Account & Token Controllers）: 为新的命名空间创建默认帐户和 API 访问令牌

Master节点流程

kubectl是客户端管理工具，主要操作的激素apiserver, 提供一个rest风格的请求， apiserver会将kubectl请求的信息（如delete、update、create请求） 存储到etcd数据中，再通过apiserver交由kube-scheduler 调度，etcd和 kube-scheduler 是不能直接通信的，调度之后再通过controller-manager 协同工作绑定到某个 具体工作节点上;

1.2 Node 组件

节点组件在每个节点上运行，维护运行的 Pod 并提供 Kubernetes 运行环境。

1.2.1 kubelet

一个在集群中每个工作节点上都运行一个kubelet服务进程，默认监听10250端口，接收并执 行master发来的指令，管理Pod及Pod中的容器。每个kubelet进程会在API Server上注册节 点自身信息，定期向master节点汇报节点的资源使用情况，整个容器运行接口都是由kubelet帮忙协调完成的；

1.2.2 kube-proxy

负责网络代理，处理外面用户如何访问容器，维护网络规则；
一个在集群中每台工作节点上都应该运行一个kube-proxy服务，它监听API server中service 和endpoint的变化情况，并通过iptables等来为服务配置负载均衡，是让我们的服务在集群 外可以被访问到的重要方式。