Docker(23)——Kubernetes(k8s)基础理论知识

首先呢？介绍一下Kubernetes的定义和作用

Kubernetes 是什么意思? K8s?

名称 Kubernetes 源于希腊语，意为 “舵手” 或 “飞行员”， 且是英文 “governor” 和 “cybernetic”的词根。 K8s 是通过将 8 个字母 “ubernete” 替换为 8 而导出的缩写。另外，在中文里，k8s 的发音与 Kubernetes 的发音比较接近。

Kubernetes概述

Kubernetes是一个开源的，用于管理云平台中多个主机上的容器化的应用，Kubernetes的目标是让部署容器化的应用简单并且高效（powerful）,减轻在公共云或私有云运行应用程序的负担。Kubernetes 具有如下特点:,Kubernetes提供了应用部署，规划，更新，维护的一种机制。

传统的应用部署方式是通过插件或脚本来安装应用。这样做的缺点是应用的运行、配置、管理、所有生存周期将与当前操作系统绑定，这样做并不利于应用的升级更新/回滚等操作，当然也可以通过创建虚拟机的方式来实现某些功能，但是虚拟机非常重，并不利于可移植性。

新的方式是通过部署容器方式实现，每个容器之间互相隔离，每个容器有自己的文件系统 ，容器之间进程不会相互影响，能区分计算资源。相对于虚拟机，容器能快速部署，由于容器与底层设施、机器文件系统解耦的，所以它能在不同云、不同版本操作系统间进行迁移。

容器占用资源少、部署快，每个应用可以被打包成一个容器镜像，每个应用与容器间成一对一关系也使容器有更大优势，使用容器可以在build或release 的阶段，为应用创建容器镜像，因为每个应用不需要与其余的应用堆栈组合，也不依赖于生产环境基础结构，这使得从研发到测试、生产能提供一致环境。类似地，容器比虚拟机轻量、更“透明”，这更便于监控和管理。

Kubernetes也是Google开源的一个容器编排引擎，它支持自动化部署、大规模可伸缩、应用容器化管理。在生产环境中部署一个应用程序时，通常要部署该应用的多个实例以便对应用请求进行负载均衡。

在Kubernetes中，我们可以创建多个容器，每个容器里面运行一个应用实例，然后通过内置的负载均衡策略，实现对这一组应用实例的管理、发现、访问，而这些细节都不需要运维人员去进行复杂的手工配置和处理。

使用 Kubernetes, 您可以快速高效地响应客户需求:

• 快速、可预测地部署您的应用程序
• 拥有即时扩展应用程序的能力
• 不影响现有业务的情况下，无缝地发布新功能
• 优化硬件资源，降低成本

Kubernetes 特点

• 可移植: 支持公有云，私有云，混合云，多云架构
• 可扩展: 模块化，插件化，可挂载，可组合
• 自动化: 自动部署，自动重启，自动复制，自动伸缩/扩展，通过声明式语法提供了强大的自修复能力

为什么是容器?

传统部署应用程序的方式

一般是使用操作系统自带的包管理器在主机上安装应用依赖，之后再安装应用程序。这无疑将应用程序的可执行文件、应用的配置、应用依赖库和应用的生命周期与宿主机操作系统进行了紧耦合。在此情境下，可以通过构建不可改变的虚拟机镜像版本，通过镜像版本实现可预测的发布和回滚，但是虚拟机实在是太重量级了，且镜像体积太庞大，便捷性差。

新部署应用程序方式

是基于操作系统级虚拟化而不是硬件级虚拟化方法来部署容器。容器之间彼此隔离并与主机隔离：它们具有自己的文件系统，不能看到彼此的进程，并且它们所使用的计算资源是可以被限制的。它们比虚拟机更容易构建，并且因为它们与底层基础架构和主机文件系统隔离，所以它们可以跨云和操作系统快速分发。

由于容器体积小且启动快，因此可以在每个容器镜像中打包一个应用程序。这种一对一的应用镜像关系拥有很多好处。使用容器，不需要与外部的基础架构环境绑定, 因为每一个应用程序都不需要外部依赖，更不需要与外部的基础架构环境依赖。完美解决了从开发到生产环境的一致性问题。

容器同样比虚拟机更加透明，这有助于监测和管理。尤其是容器进程的生命周期由基础设施管理，而不是由容器内的进程对外隐藏时更是如此。最后，每个应用程序用容器封装，管理容器部署就等同于管理应用程序部署。

容器优点摘要:

• 敏捷的应用程序创建和部署: 与虚拟机镜像相比，容器镜像更容易创建，提升了硬件的使用效率。
• 持续开发、集成和部署: 提供可靠与频繁的容器镜像构建和部署，可以很方便及快速的回滚 (由于镜像不可变性).
• 关注开发与运维的分离: 在构建/发布时创建应用程序容器镜像，从而将应用程序与基础架构分离。
  -开发、测试和生产环境的一致性: 在笔记本电脑上运行与云中一样。
• 云和操作系统的可移植性: 可运行在 Ubuntu, RHEL, CoreOS, 内部部署, Google 容器引擎和其他任何地方。
• 以应用为中心的管理: 提升了操作系统的抽象级别，以便在使用逻辑资源的操作系统上运行应用程序。
• 松耦合、分布式、弹性伸缩 微服务: 应用程序被分成更小，更独立的部分，可以动态部署和管理 - 而不是巨型单体应用运行在专用的大型机上。
• 资源隔离: 通过对应用进行资源隔离，可以很容易的预测应用程序性能。
• 资源利用: 高效率和高密度。

Kubernetes实现的目标

最基础的，Kubernetes 可以在物理或虚拟机集群上调度和运行应用程序容器。然而，Kubernetes 还允许开发人员从物理和虚拟机’脱离’，从以主机为中心的基础架构转移到以容器为中心的基础架构，这样可以提供容器固有的全部优点和益处。Kubernetes 提供了基础设施来构建一个真正以容器为中心的开发环境。

Kubernetes 满足了生产中运行应用程序的许多常见的需求,，例如：

• Pod 提供复合应用并保留一个应用一个容器的容器模型,
• 挂载外部存储,
• Secret管理,
• 应用健康检查,
• 副本应用实例,
• 横向自动扩缩容,
• 服务发现,
• 负载均衡,
• 滚动更新,
• 资源监测,
• 日志采集和存储,
• 支持自检和调试,
• 认证和鉴权.
  这提供了平台即服务 (PAAS) 的简单性以及基础架构即服务 (IAAS) 的灵活性，并促进跨基础设施供应商的可移植性。

为什么 Kubernetes 是一个平台?

Kubernetes 提供了很多的功能，总会有新的场景受益于新特性。它可以简化应用程序的工作流，加快开发速度。被大家认可的应用编排通常需要有较强的自动化能力。这就是为什么 Kubernetes 被设计作为构建组件和工具的生态系统平台，以便更轻松地部署、扩展和管理应用程序。

Label 允许用户按照自己的方式组织管理对应的资源。 注解 使用户能够以自定义的描述信息来修饰资源，以适用于自己的工作流，并为管理工具提供检查点状态的简单方法。

此外，Kubernetes 控制面 (Control Plane) 是构建在相同的 APIs 上面，开发人员和用户都可以用。用户可以编写自己的控制器， 调度器等等，如果这么做，根据新加的自定义 API ，可以扩展当前的通用 CLI 命令行工具。

这种 设计 使得许多其他系统可以构建在 Kubernetes 之上

Kubernetes 不是什么:

Kubernetes 不是一个传统意义上，包罗万象的 PaaS (平台即服务) 系统。我们保留用户选择的自由，这非常重要。

• Kubernetes 不限制支持的应用程序类型。 它不插手应用程序框架 (例如 Wildfly), 不限制支持的语言运行时 (例如 Java, Python, Ruby)，只迎合符合 12种因素的应用程序，也不区分”应用程序”与”服务”。Kubernetes 旨在支持极其多样化的工作负载，包括无状态、有状态和数据处理工作负载。如果应用可以在容器中运行，它就可以在 Kubernetes 上运行。
• Kubernetes 不提供作为内置服务的中间件 (例如 消息中间件)、数据处理框架 (例如 Spark)、数据库 (例如 mysql)或集群存储系统 (例如 Ceph)。这些应用可以运行在 Kubernetes 上。
• Kubernetes 没有提供点击即部署的服务市场
• Kubernetes 从源代码到镜像都是非垄断的。 它不部署源代码且不构建您的应用程序。 持续集成 (CI) 工作流是一个不同用户和项目都有自己需求和偏好的领域。 所以我们支持在 Kubernetes 分层的 CI 工作流，但不指定它应该如何工作。
• Kubernetes 允许用户选择其他的日志记录，监控和告警系统 (虽然我们提供一些集成作为概念验证)
• Kubernetes 不提供或授权一个全面的应用程序配置语言/系统 (例如 jsonnet).
• Kubernetes 不提供也不采用任何全面机器配置、保养、管理或自我修复系统

另一方面，许多 PaaS 系统运行 在 Kubernetes 上面，例如 Openshift, Deis, and Eldarion。 您也可以自定义您自己的 PaaS, 与您选择的 CI 系统集成，或与 Kubernetes 一起使用: 将您的容器镜像部署到 Kubernetes。

由于 Kubernetes 在应用级别而不仅仅在硬件级别上运行，因此它提供 PaaS 产品通用的一些功能，例如部署、扩展、负载均衡、日志记录、监控等。但是，Kubernetes 不是单一的，默认解决方案是可选和可插拔的。

此处，Kubernetes 不仅仅是一个 “编排系统”；它消除了编排的需要。 “编排”技术定义的是工作流的执行: 从 A 到 B，然后到 C。相反，Kubernetes 是包括一套独立、可组合的控制过程，通过声明式语法使其连续地朝着期望状态驱动当前状态。 不需要告诉它具体从 A 到 C 的过程，只要告诉到 C 的状态即可。 也不需要集中控制；该方法更类似于”编舞”。这使得系统更容易使用并且更强大、更可靠、更具弹性和可扩展性。

Kubernetes 组件

• Master 组件
• 节点组件

Master 组件

Master 组件提供的集群控制。Master 组件对集群做出全局性决策(例如：调度)，以及检测和响应集群事件(副本控制器的replicas字段不满足时,启动新的副本)。

Master 组件可以在集群中的任何节点上运行。然而，为了简单起见，设置脚本通常会启动同一个虚拟机上所有 Master 组件，并且不会在此虚拟机上运行用户容器。请参阅构建高可用性群集示例对于多主机 VM 的设置。

API服务器

kube-apiserver对外暴露了Kubernetes API。它是的 Kubernetes 前端控制层。它被设计为水平扩展，即通过部署更多实例来缩放。
当然，我们可能是通过命令行的kubectl命令将一个yaml/json格式的文件create进行创建，还可能是通过写代码的方式使用如client-go这样的操作Kubernetes的第三方包来操作集群。总之，最终，都是通过API Server对集群进行操作的。通过API Server，我们就可以往Etcd中写入数据。Etcd中存储着集群的各种数据。

etcd

etcd 用于 Kubernetes 的后端存储。所有集群数据都存储在此处，始终为您的 Kubernetes 集群的 etcd 数据提供备份计划。

kube-controller-manager

kube-controller-manager运行控制器，它们是处理集群中常规任务的后台线程。逻辑上，每个控制器是一个单独的进程，但为了降低复杂性，它们都被编译成独立的可执行文件，并在单个进程中运行。
这些控制器包括:

• 节点控制器(Node Controller): 当节点移除时，负责注意和响应。
• 副本控制器(Replication Controller): 负责维护系统中每个副本控制器对象正确数量的 Pod。
  端点控制器(Endpoints Controller): 填充 端点(Endpoints) 对象(即连接 Services & Pods)。

   1、负责生成和维护所有Endpoints对象的控制器。Endpoints表示了一个Service对应的所有Pod副本的访问地址。
   2、一个Service可能对应了多个Endpoints，那么，在创建一个新的Service时Endpoints Controller就会生成对应的Endpoints。在Service被删除时，Endpoints Controller就会删除对应的Endpoints。等等。

• 服务帐户和令牌控制器(Namespace Controller): 为新的命名空间创建默认帐户和 API 访问令牌.

Namespace Controller:用户是可以通过API Server创建新的namespace并保存在Etcd中的。Namespace Controller会定时通过API Server读取这些Namespace信息并做对应的对于Namespace的一些操作。

Node Controller

通过API Server监控Etcd中存储的关于节点的各类信息，这些信息是kubelet定时推给API Server的，由API Server写入到Etcd中。这些节点信息包括：节点健康状况、节点资源、节点名称、节点地址信息、操作系统版本、Docker版本、kubelet版本等。监控到节点信息若有异常情况，则会对节点进行某种操作，如节点状态变为故障状态，则删除节点与节点相关的Pod等资源的信息。

云控制器管理器-(cloud-controller-manager)

cloud-controller-manager 是用于与底层云提供商交互的控制器。云控制器管理器可执行组件是 Kubernetes v1.6 版本中引入的 Alpha 功能。
cloud-controller-manager 仅运行云提供商特定的控制器循环。您必须在 kube-controller-manager 中禁用这些控制器循环，您可以通过在启动 kube-controller-manager 时将 --cloud-provider标志设置为external来禁用控制器循环。

cloud-controller-manager 允许云供应商代码和 Kubernetes 核心彼此独立发展，在以前的版本中，Kubernetes 核心代码依赖于云提供商特定的功能代码。在未来的版本中，云供应商的特定代码应由云供应商自己维护，并与运行 Kubernetes 的云控制器管理器相关联。

以下控制器具有云提供商依赖关系:

  节点控制器: 用于检查云提供商以确定节点是否在云中停止响应后被删除
  路由控制器: 用于在底层云基础架构中设置路由
  服务控制器: 用于创建，更新和删除云提供商负载平衡器
  数据卷控制器: 用于创建，附加和装载卷，并与云提供商进行交互以协调卷

调度器 - (kube-scheduler)

kube-scheduler监视没有分配节点的新创建的 Pod，选择一个节点供他们运行。

Kubernetes的调度器。Scheduler监听API Server，当需要创建新的Pod时。Scheduler负责选择该Pod与哪个Node进行绑定。将此绑定信息通过API Server写入到Etcd中。

若此时与Node A进行了绑定，那么A上的Kubelet就会从API Server上监听到此事件，那么该Kubelet就会做相应的创建工作。

此调度涉及到三个对象，待调度的Pod，可用的Node，调度算法。简单的说，就是使用某种调度算法为待调度的Pod找到合适的运行此Pod的Node。

插件(addons)

插件是实现集群功能的 Pod 和 Service。 Pods 可以通过 Deployments，ReplicationControllers 管理。插件对象本身是受命名空间限制的，被创建于 kube-system 命名空间。

Addon 管理器用于创建和维护附加资源.

DNS

虽然其他插件并不是必需的，但所有 Kubernetes 集群都应该具有Cluster DNS，许多示例依赖于它。

Cluster DNS 是一个 DNS 服务器，和您部署环境中的其他 DNS 服务器一起工作，为 Kubernetes 服务提供DNS记录。
Kubernetes 启动的容器自动将 DNS 服务器包含在 DNS 搜索中。

用户界面

dashboard 提供了集群状态的只读概述。有关更多信息，请参阅使用HTTP代理访问 Kubernetes API

容器资源监控

容器资源监控将关于容器的一些常见的时间序列度量值保存到一个集中的数据库中，并提供用于浏览这些数据的界面。

集群层面日志

集群层面日志 机制负责将容器的日志数据保存到一个集中的日志存储中，该存储能够提供搜索和浏览接口。

节点组件

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

kubelet

kubelet是主要的节点代理,它监测已分配给其节点的 Pod(通过 apiserver 或通过本地配置文件)，提供如下功能:

挂载 Pod 所需要的数据卷(Volume)。
下载 Pod 的 secrets。
通过 Docker 运行(或通过 rkt)运行 Pod 的容器。
周期性的对容器生命周期进行探测。
如果需要，通过创建 镜像 Pod（Mirror Pod） 将 Pod 的状态报告回系统的其余部分。
将节点的状态报告回系统的其余部分。

kube-proxy

kube-proxy通过维护主机上的网络规则并执行连接转发，实现了Kubernetes服务抽象。

docker

Docker 用于运行容器。

rkt

支持 rkt 运行容器作为 Docker 的试验性替代方案。

supervisord

supervisord 是一个轻量级的进程监控系统，可以用来保证 kubelet 和 docker 运行。

fluentd

fluentd 是一个守护进程，它有助于提供集群层面日志 集群层面的日志。