Kubernetes-0 引入 | zの自留地

1. K8S是什么？
- 1.1 概述
2. 为什么需要K8S？
3. K8S有哪些组件？
4. 特性对比
5. 总结

# 1. K8S是什么？

# 1.1 概述

K8S全名Kubernetes。因k与s之间有8个字符，故缩写为K8S。

K8S是一个可自动实施 Linux 容器管理的可移植、可扩展的开源平台，用于管理容器化的工作负载和服务，可促进声明式配置和自动化。

# 2. 为什么需要K8S？

要了解这个问题，需要回顾一下应用程序的部署方式。

# 2.1 传统部署

传统部署直接在物理服务器上运行应用程序。存在缺陷：

无法为服务器中的应用程序定义资源边界，导致资源分配出现问题（一个程序占用大部分资源，其它程序性能下降）。
若将应用程序运行在不同物理服务器上，一方面导致资源浪费，另一方面提高成本。

# 2.2 虚拟化部署

虚拟化技术允许我们在单个的物理服务器上运行多个虚拟机（VM），应用程序在VM之间完全隔离。

每个VM是一个完整的计算机，在虚拟化硬件上运行包括自己的操作系统在内的所有组件。VM共享主机硬件资源。

但因为VM需要运行硬件虚拟副本和完整的操作系统副本，会占用大量的系统资源。

# 2.3 容器部署

容器将应用程序软件代码和所需的所有组件打包在一起，使得容器内的用意可以在任何基础架构上一致的运行。

隔离性：容器同样可以虚拟化基础计算机，应用程序可在不同容器间实现进程级隔离。
轻量性：每个容器共享物理服务器的OS内核，二进制文件和库，但具有自己的文件系统、CPU、内存、进程空间等。这样的共享可以大大减少重现操作系统代码的需求。因此容器非常轻量，容量小且启动快。
可移植：容器与基础架构分离，可以实现跨云和OS发行版本进行移植。

K8S即是在大规模服务器环境中，负责部署和管理容器组，用于解决容器的复制，扩展，健康，启动，负载均衡等问题。只需告诉 Kubernetes 您希望在哪里运行软件，该平台就会负责执行部署和管理容器所需的几乎一切工作。

# 3. K8S有哪些组件？

我们会在一组用于运行容器化应用的节点计算机（Node）的上部署K8S，这一组节点计算机即称为K8S集群。正常运行的K8S集群包含以下组件。

# 3.1 集群相关术语

控制平面（Control Plane） 控制 Kubernetes 节点的进程的集合。所有任务分配都来自于此。
节点（Node）： 这些机器负责执行由控制平面分配的请求任务。
容器集（Pod）： 部署到单个节点上且包含一个或多个容器的容器组。容器集是最小、最简单的 Kubernetes 对象。
服务（Service）： 一种将运行于一组容器集上的应用开放为网络服务的方法。它将工作定义与容器集分离。
卷（Volume）： 一个包含数据的目录，可供容器集内的容器访问。Kubernetes 卷与所在的容器集具有相同的生命周期。卷的生命周期要长于容器集内运行的所有容器的生命周期，并且在容器重新启动时会保留相应的数据。
命名空间（Namespace）： 一个虚拟集群。命名空间允许 Kubernetes 管理同一物理集群中的多个集群（针对多个团队或项目）。

# 3.2 控制平面组件

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

kube-apiserver：该组件开放 Kubernetes API。API服务器是K8S控制平面的前端。
etcd：etcd 是兼具一致性和高可用性的键值数据库，可以作为保存 Kubernetes 所有集群数据的后台数据库
kube-scheduler：该组件负责监视新创建的、为指定运行节点（node）的Pods,并选择节点让Pod在上面运行。
kube-controller-manager：运行控制器进程的控制平面组件。多中控制器被编译到一个可执行文件，并在一个进程中进行运行。
cloud-controller-manager：云控制器管理器是指嵌入特定云的控制逻辑的控制平面 (opens new window)组件。云控制器管理器使得你可以将你的集群连接到云提供商的 API 之上，并将与该云平台交互的组件同与你的集群交互的组件分离开来。

# 3.3 Node组件

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

Kubelet：每个节点上运行的代理。它保证容器都运行在Pod中。
kube-proxy：kube-proxy 是集群中每个节点上运行的网络代理，实现 Kubernetes 服务（Service） (opens new window) 概念的一部分。它维护节点上的网络规则。这些网络规则允许从集群内部或外部的网络会话与 Pod 进行网络通信。

# 3.4 容器运行时

容器运行环境是负责运行容器的软件。支持包括像Docker，iSula以及任何实现k8s CRI的容器运行环境。

# 3.5 其它可用插件

插件并非严格意义上的必须组件。仅列举以下常用的两种。

DNS：几乎所有 Kubernetes 集群都应该有集群DNS。
Web界面：Dashboard 是 Kubernetes 集群的通用的、基于 Web 的用户界面。

# 4. 特性对比

以下是物理机部署、虚拟机部署、容器化部署和 Kubernetes（K8s）部署的对比表：

特性	物理机部署	虚拟机部署	容器化部署	Kubernetes (K8s)
性能	高，直接访问硬件资源	中，虚拟化带来性能损耗	接近原生性能	接近原生性能
资源利用率	低	中等	高	高
启动时间	慢	几分钟	秒级甚至毫秒级（依赖于容器特性）	秒级（依赖于容器特性）
隔离性	强（硬件级别隔离）	强（虚拟化隔离）	中（共享操作系统内核）	中（共享内核，通过Namespace和Cgroup提供隔离）
扩展性	差	中等	强	非常强
部署难度	高（需人工维护关系表）	中等（云平台或私有云辅助管理）	低（Docker提供便捷工具）	高（架构复杂，需掌握k8s的管理方式）
运维方式	手动维护，人工操作	通过OpenStack、VMware或公有云等管理	通过Docker CLI或Docker Compose	使用kubectl、控制台或集成工具（如Rancher、KubeSphere）进行管理
环境一致性	差（依赖于硬件和操作系统）	中等（每个虚拟机环境独立）	高（提供一致的运行环境，除内核外均相同）	高（容器环境一致，支持跨云部署）
迁移性	差	中等（依赖虚拟机镜像）	高（通过Docker镜像跨平台迁移）	高（支持跨集群迁移）
扩缩容能力	差	中等（需手动调整虚拟机数量）	强（秒级扩容）	强（支持自动扩缩容）
高可用	依赖硬件冗余无	通过冗余虚拟机实现	依赖容器编排工具	内置高可用支持，通过节点和服务的冗余提供可靠性
灰度发布	无	复杂，需要独立配置	较简单，通过标签和多版本容器实现	内置支持灰度发布和流量管理
适用场景	性能敏感应用，对硬件依赖强	中小规模应用，兼顾成本和隔离性	轻量级部署，快速迭代的微服务架构	大规模分布式系统，高并发、动态扩容需求
管理工具	无（人工维护）	OpenStack、VMware、云平台	Docker CLI、Docker Compose	kubectl、Rancher、KubeSphere等工具
缺点	资源浪费，无法快速扩容，自动化运维难	运维复杂度高，资源效率低于容器化	容器数量庞大时，手动管理难度较大	系统复杂度较高，初学者学习门槛较高

# 5. 总结

不同的部署方式适用于不同的场景。随着需求的变化，可以从简单到复杂逐步演进。

Kubernetes 是当前云原生技术的核心，但也需要根据团队能力和业务需求选择适合的部署方式。

打赏一下

「真诚赞赏，手留余香」

# 打赏记录

打赏者	打助金额 (元)	支付方式	时间	备注
John	12	微信	2020-06-09
艾斯	32	支付宝	2020-07-11	nice
HickSalmon	15	微信	2020-09-21	有赏交流