Kubernetes容器云基础知识

文章目录

• 一、Kubernetes是什么？
• 二、kubernetes特性
• 三、Kubernetes集群架构与组件
• 四、Kubernetes API
• 五、kubernetes核心概念

一、Kubernetes是什么？

1.1 Kubernetes的概述

• Kubernetes是Google在2014年开源的一个容器集群管理系统，Kubernetes简称k8S。
• K8S用于容器化应用程序的部署，扩展和管理。
• K8S提供了容器编排，资源调度，弹性伸缩，部署管理，服务发现停一系列功能。
• Kubernetes目标是让部署容器化应用简单高效。
• 官方网站：https://kubernetes.io/

1.2 为什么 Kubernetes 如此有用？

传统部署时代： 早期，组织在物理服务器上运行应用程序。无法为物理服务器中的应用程序定义资源边界，这会导致资源分配问题。例如，如果在物理服务器上运行多个应用程序，则可能会出现一个应用程序占用大部分资源的情况，结果可能导致其他应用程序的性能下降。一种解决方案是在不同的物理服务器上运行每个应用程序，但是由于资源利用不足而无法扩展，并且组织维护许多物理服务器的成本很高。

虚拟化部署时代： 作为解决方案，引入了虚拟化功能，它允许您在单个物理服务器的 CPU 上运行多个虚拟机（VM）。虚拟化功能允许应用程序在 VM 之间隔离，并提供安全级别，因为一个应用程序的信息不能被另一应用程序*地访问。

因为虚拟化可以轻松地添加或更新应用程序、降低硬件成本等等，所以虚拟化可以更好地利用物理服务器中的资源，并可以实现更好的可伸缩性。

每个 VM 是一台完整的计算机，在虚拟化硬件之上运行所有组件，包括其自己的操作系统。

容器部署时代： 容器类似于 VM，但是它们具有轻量级的隔离属性，可以在应用程序之间共享操作系统（OS）。因此，容器被认为是轻量级的。容器与 VM 类似，具有自己的文件系统、CPU、内存、进程空间等。由于它们与基础架构分离，因此可以跨云和 OS 分发进行移植。

容器因具有许多优势而变得流行起来。下面列出了容器的一些好处：

• 敏捷应用程序的创建和部署：与使用 VM 镜像相比，提高了容器镜像创建的简便性和效率。
• 持续开发、集成和部署：通过快速简单的回滚(由于镜像不可变性)，提供可靠且频繁的容器镜像构建和部署。
• 关注开发与运维的分离：在构建/发布时而不是在部署时创建应用程序容器镜像，从而将应用程序与基础架构分离。
• 可观察性不仅可以显示操作系统级别的信息和指标，还可以显示应用程序的运行状况和其他指标信号。
• 跨开发、测试和生产的环境一致性：在便携式计算机上与在云中相同地运行。
• 云和操作系统分发的可移植性：可在 Ubuntu、RHEL、CoreOS、本地、Google Kubernetes Engine 和其他任何地方运行。
• 以应用程序为中心的管理：提高抽象级别，从在虚拟硬件上运行 OS 到使用逻辑资源在 OS 上运行应用程序。
• 松散耦合、分布式、弹性、解放的微服务：应用程序被分解成较小的独立部分，并且可以动态部署和管理 - 而不是在一台大型单机上整体运行。
• 资源隔离：可预测的应用程序性能。
• 资源利用：高效率和高密度。

二、kubernetes特性

2.1 为什么需要 Kubernetes，它能做什么?

容器是打包和运行应用程序的好方式。在生产环境中，您需要管理运行应用程序的容器，并确保不会停机。例如，如果一个容器发生故障，则需要启动另一个容器。如果系统处理此行为，会不会更容易？
这就是 Kubernetes 的救援方法！Kubernetes 提供了一个可弹性运行分布式系统的框架。Kubernetes 会满足您的扩展要求、故障转移、部署模式等。例如，Kubernetes 可以轻松管理系统的 Canary 部署。

• 自我修复
  在节点故障时重新启动失败的容器，替换和重新部署，保证预期的副本数量，杀死健康检查失败的容器，并且在未准备好之前不会处理客户端请求，确保线上服务不中断。
• 弹性伸缩
  使用命令、U或者基于CPU使用情况自动快速扩容和缩容应用程序实例，保证应用业务高峰并发时的高可用性;业务低峰时回收资源，以最小成本运行服务。
• 自动部署和回滚
  K8S采用滚动更新策略更新应用，一次更新一个Pod，而不是同时删除所有Pod，如果更新过程中出现问题，将回滚更改，确保升级不受影响业务。
• 服务发现和负载均衡
  K8S为多个容器提供一个统一访问入口（内部IP地址和一个DNS名称)，并且负载均衡关联的所有容器，使得用户无需考虑容器IP问题。
• 机密和配置管理
  管理机密数据和应用程序配置，而不需要把敏感数据暴露在镜像里，提高敏感数据安全性。并可以将一些常用的配置存储在K8S中，方便应用程序使用。
• 存储编排
  挂载外部存储系统，无论是来自本地存储，公有云(如AWNS)），还是网络存储(如NFS、GlusterFS. Ceph）都作为集群资源的一部分使用，极大提高存储使用灵活性。
• 批处理
  提供一次性任务，定时任务;满足批量数据处理和分析的场景。

2.2 Kubernetes 不是什么？

Kubernetes 不是传统的、包罗万象的 PaaS（平台即服务）系统。由于 Kubernetes 在容器级别而不是在硬件级别运行，因此它提供了 PaaS 产品共有的一些普遍适用的功能，例如部署、扩展、负载均衡、日志记录和监视。但是，Kubernetes 不是单一的，默认解决方案是可选和可插拔的。Kubernetes 提供了构建开发人员平台的基础，但是在重要的地方保留了用户的选择和灵活性。

• Kubernetes 不限制支持的应用程序类型。Kubernetes 旨在支持极其多种多样的工作负载，包括无状态、有状态和数据处理工作负载。如果应用程序可以在容器中运行，那么它应该可以在 Kubernetes 上很好地运行。
• Kubernetes 不部署源代码，也不构建您的应用程序。持续集成(CI)、交付和部署（CI/CD）工作流取决于组织的文化和偏好以及技术要求。
• Kubernetes 不提供应用程序级别的服务作为内置服务，例如中间件（例如，消息中间件）、数据处理框架（例如，Spark）、数据库（例如，mysql）、缓存、集群存储系统（例如，Ceph）。这样的组件可以在 Kubernetes 上运行，并且/或者可以由运行在 Kubernetes 上的应用程序通过可移植机制（例如，开放服务代理）来访问。
• Kubernetes 不指定日志记录、监视或警报解决方案。它提供了一些集成作为概念证明，并提供了收集和导出指标的机制。
• Kubernetes 不提供或不要求配置语言/系统（例如 jsonnet），它提供了声明性 API，该声明性 API 可以由任意形式的声明性规范所构成。
• Kubernetes 不提供也不采用任何全面的机器配置、维护、管理或自我修复系统。
• 此外，Kubernetes 不仅仅是一个编排系统，实际上它消除了编排的需要。编排的技术定义是执行已定义的工作流程：首先执行 A，然后执行 B，再执行 C。相比之下，Kubernetes 包含一组独立的、可组合的控制过程，这些过程连续地将当前状态驱动到所提供的所需状态。从 A 到 C 的方式无关紧要，也不需要集中控制，这使得系统更易于使用且功能更强大、健壮、弹性和可扩展性。

三、Kubernetes集群架构与组件

部署完 Kubernetes, 即拥有了一个完整的集群。

一个 Kubernetes 集群包含 集群由一组被称作节点的机器组成。这些节点上运行 Kubernetes 所管理的容器化应用。集群具有至少一个工作节点和至少一个主节点。
工作节点托管作为应用程序组件的 Pod 。主节点管理集群中的工作节点和 Pod 。多个主节点用于为集群提供故障转移和高可用性。

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

控制平面的组件对集群做出全局决策(比如调度)，以及检测和响应集群事件（例如，当不满足部署的 replicas 字段时，启动新的 pod）。
控制平面组件可以在集群中的任何节点上运行。 然而，为了简单起见，设置脚本通常会在同一个计算机上启动所有控制平面组件，并且不会在此计算机上运行用户容器。

• kube-apiserver
  Kubernetes API，集群的统一入口，各组件协调者，以RESTful API提供接口服务，所有对象资源的增删改查和监听操作都交给APIServer处理后再提交给Etcd存储。
• etcd
  分布式键值存储系统。用于保存集群状态数据，比如Pod、Service等对象信息。
• kube-scheduler
  根据调度算法为新创建的Pod选择一个Node节点，可以任意部署,可以部署在同一个节点上,也可以部署在不同的节点上。
• kube-controller-manager
  处理集群中常规后台任务，一个资源对应一个控制器，而ControllerManager
  就是负责管理这些控制器的。
  这些控制器包括:
  • 节点控制器（Node Controller）: 负责在节点出现故障时进行通知和响应。
  • 副本控制器（Replication Controller）: 负责为系统中的每个副本控制器对象维护正确数量的 Pod。
  • 端点控制器（Endpoints Controller）: 填充端点(Endpoints)对象(即加入 Service 与 Pod)。
  • 服务帐户和令牌控制器（Service Account & Token Controllers）: 为新的命名空间创建默认帐户和 API 访问令牌

3.2 Node组件

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

• kubelet
  kubelet是Master在Node节点上的Agent，管理本机运行容器的生命周期，比如创建容器、Pod挂载数据卷、下载secret、获取容器和节点状态等工作。kubelet将每个Pod转换成一组容器。
• kube-proxy
  在Node节点上实现Pod网络代理，维护网络规则和四层负载均衡工作。
• docker或rocket
  容器引擎，运行容器。

四、Kubernetes API

Kubernetes 控制面 的核心是 API 服务器。 API 服务器负责提供 HTTP API，以供用户、集群中的不同部分和集群外部组件相互通信。

Kubernetes API 使你可以查询和操纵 Kubernetes API 中对象（例如：Pod、Namespace、ConfigMap 和 Event）的状态。

4.1 API 变更

任何成功的系统都要随着新的使用案例的出现和现有案例的变化来成长和变化。 为此，Kubernetes 的功能特性设计考虑了让 Kubernetes API 能够持续变更和成长的因素。 Kubernetes 项目的目标是 不要 引发现有客户端的兼容性问题，并在一定的时期内 维持这种兼容性，以便其他项目有机会作出适应性变更。

一般而言，新的 API 资源和新的资源字段可以被频繁地添加进来。 删除资源或者字段则要遵从 API 废弃策略。

4.2 OpenAPI 规范

完整的 API 细节是用 OpenAPI 来表述的。

Kubernetes API 服务器通过 /openapi/v2 末端提供 OpenAPI 规范。 你可以按照下表所给的请求头部，指定响应的格式：

头部	可选值	说明
Accept-Encoding	gzip	不指定此头部也是可以的
不指定此头部也是可以的	application/com.github.proto-openapi.spec.v2@v1.0+protobuf	主要用于集群内部
	application/json	默认值
	*	提供application/json

OpenAPI v2 查询请求的合法头部值
Kubernetes 为 API 实现了一种基于 Protobuf 的序列化格式，主要用于集群内部的通信。

4.3 API 版本

为了简化删除字段或者重构资源表示等工作，Kubernetes 支持多个 API 版本， 每一个版本都在不同 API 路径下，例如 /api/v1 或 /apis/rbac.authorization.k8s.io/v1alpha1。

版本化是在 API 级别而不是在资源或字段级别进行的，目的是为了确保 API 为系统资源和行为提供清晰、一致的视图，并能够控制对已废止的和/或实验性 API 的访问。

JSON 和 Protobuf 序列化模式遵循 schema 更改的相同准则 - 下面的所有描述都同时适用于这两种格式。

请注意，API 版本控制和软件版本控制只有间接相关性。 Kubernetes 发行版本提案中描述了 API 版本与软件版本之间的关系。

不同的 API 版本名称意味着不同级别的软件稳定性和支持程度。 每个级别的判定标准在 API 变更文档 中有更详细的描述。 这些标准主要概括如下：

Alpha 级别：

• 版本名称包含 alpha（例如：v1alpha1）
• API 可能是有缺陷的。启用该功能可能会带来问题，默认情况是禁用的
• 对相关功能的支持可能在没有通知的情况下随时终止
• API 可能在将来的软件发布中出现不兼容性的变更，此类变更不会另行通知
• 由于缺陷风险较高且缺乏长期支持，推荐仅在短暂的集群测试中使用

Beta 级别：

• 版本名称包含 beta（例如：v2beta3）
• 代码已经充分测试过。启用该功能被认为是安全的，功能默认已启用。
• 所支持的功能作为一个整体不会被删除，尽管细节可能会发生变更。
• 对象的模式和/或语义可能会在后续的 beta 发行版或稳定版中以不兼容的方式进行更改。 发生这种情况时，我们将提供如何迁移到新版本的说明。 迁移操作可能需要删除、编辑和重新创建 API 对象。 执行编辑操作时可能需要动些脑筋。 迁移过程中可能需要停用依赖该功能的应用程序。
• 建议仅用于非业务关键性用途，因为后续版本中可能存在不兼容的更改。 如果你有多个可以独立升级的集群，则可以放宽此限制。

稳定级别：

• 版本名称是 vX，其中 X 是整数。
• 功能的稳定版本将出现在许多后续版本的发行软件中

4.4 API 组

为了更容易地扩展 Kubernetes API，Kubernetes 实现了 API组。 API 组在 REST路径和序列化对象的apiVersion字段中指定。

集群中存在若干 API 组：

• *核心（Core）*组，通常被称为 遗留（Legacy） 组，位于 REST 路径 /api/v1， 使用 apiVersion: v1。
• 命名（Named） 组 REST 路径 /apis/$GROU{P}_{N}AME/$VERSION，使用 apiVersion: $GROU{P}_{N}AME/$VERSION（例如 apiVersion: batch/v1）。 Kubernetes API 参考中枚举了可用的 API 组的完整列表。

有两种途径来扩展 Kubernetes API 以支持 自定义资源：

• 使用 CustomResourceDefinition， 你可以用声明式方式来定义 API 如何提供你所选择的资源 API。
• 也可以选择实现自己的扩展 API 服务器 并使用聚合器 为客户提供无缝的服务。

4.5 启用或禁用 API 组

某些资源和 API 组默认情况下处于启用状态。可以通过为 kube-apiserver 设置 --runtime-config 命令行选项来启用或禁用它们。 --runtime-config 接受逗号分隔的值。 例如：要禁用 batch/v1，设置 --runtime-config=batch/v1=false； 要启用 batch/v2alpha1，设置–runtime-config=batch/v2alpha1。 该标志接受逗号分隔的一组"key=value"键值对，用以描述 API 服务器的运行时配置。

说明： 启用或禁用组或资源需要重新启动 kube-apiserver 和 kube-controller-manager 来使得 --runtime-config 更改生效。

五、kubernetes核心概念

Pod

• 最小部署单元
• 一组容器的集合
• 一个Pod中的容器共享网络命名空间
• Pod是短暂的

Controllers

• ReplicaSet :确保预期的Pod副本数量
• Deployment:无状态应用部署
• StatefulSet :有状态应用部署
• DaemonSet:确保所有Node运行同一个Pod
• Job :一次性任务
• Cronjob :定时任务

更高级层次对象，部署和管理Pod

Service

• 防止Pod失联
• 定义一组Pod的访问策略

Label:标签,附加到某个资源上，用于关联对象、查询和筛选

Namespaces:命名空间，将对象逻辑上隔离

Annotations:注释

本文地址：https://blog.csdn.net/weixin_47153988/article/details/108835717