【职场技术栈学习实录】Kubernetes 详解（一）—

本文链接：https://blog.youkuaiyun.com/driftingalone98/article/details/146454794

系列文章介绍

本系列是我作为一名后端开发，在日常工作中积累的技术学习与实践笔记。在这里，我将分享工作中后端开发领域的技术栈、架构设计、代码实现以及问题解决的经验与心得。出于保护公司隐私的原因，实际业务场景无法详细展开，但我会通过抽象化的需求和通用的技术问题，来介绍与探讨如何在实际工作中应用这些技术。

前言

K8S中有非常多的概念和专业术语，如果理解了这些概念，上手K8S的具体操作是非常快的。因此，在这篇博客中，我会详细介绍K8S的前世今生和集群架构。

近些年我们正越来越多地听到一个概念——“云原生”，而Kubernetes（下文简称为K8S）作为云原生技术的核心组件之一，是现如今企业云原生系统的主流解决方案，也正在成为后端开发所必须要了解和使用的一项技术。现在实习公司的基础架构平台正是基于K8S所搭建的，为了更好上手公司业务，并拓展自己的技术深度与广度，特此开辟K8S专题技术博客，记录自己的所学、所想、所悟。

一、Kubernetes是什么？为什么要使用它？

个人对技术的学习理解中，在学习某一项技术前，我都会去了解一下这个技术的前世今生，我认为技术没有横空出世的，是为了解决某些之前的技术没有解决的问题，进而演化成一套解决方案，K8S也正是如此。

作为一名后端开发程序员，程序在开发、测试都没问题后，便是部署上线。20年前，是将程序直接部署在服务器或虚拟机上。10年前，出现了容器化的概念。现如今，我们有了K8S。那么为什么我们需要使用K8S呢？之前的方案有哪些问题呢？接下来我们以部署Java程序为例，详细阐述三者之间的优劣差异。

1. 传统部署与虚拟机部署

传统部署中，我们将程序打包，部署在一个Tomcat服务器中。如果程序只有一个是没问题的，可程序如果有多个，问题就产生了。由于他们会共享服务器的公共资源——CPU、操作系统、网络、缓存、硬盘等资源，可能导致冲突和安全风险。而且，更新与修补依赖于人工操作，容易引发配置漂移和环境不一致问题。
虚拟化部署，则是将服务器中开辟多个虚拟机，每个虚拟机中存放着一个程序，每个程序都有独立的内核和操作系统，互不干扰，解决了资源冲突的问题。但所有程序都对应着一个独立的操作系统，系统的开销非常大。同时，当程序越来越多时，会创造非常多的虚拟机，资源调度和管理难度会越来越高。
在这里插入图片描述

2. 容器化部署

不同于前两者，容器化部署将应用及其依赖打包到轻量级的容器中，共享宿主机操作系统内核，但在进程及资源上实现隔离。代表性技术就是我们所熟知的Docker。它的优势是很明显的。

资源利用率高：无需加载完整操作系统，启动快，占用资源少。
部署灵活：镜像一致性保证了开发、测试和生产环境一致，便于部署和迁移。
高效开发流程：支持快速构建、分发和更新应用。

在Docker中，我们会将打包好的应用程序制作成一个镜像，也就是docker image。我们将这个image上传到仓库中，需要时只需将其从仓库中拉取下来，也就是docker pull。而部署也非常简单，直接docker run，指定镜像，暴露其外部端口便可以从外部去访问这个容器中的实例。将复杂的流程转变为简单、直接、高效的几个指令，大大简化了部署的难度。
在这里插入图片描述

3. 容器编排部署 K8S

Docker已经很方便了，那么为什么还需要K8S呢？

这便要讨论Docker的一大痛点，在面对小型项目时，它十分方便。但是，一旦服务器中应用服务变多，应用规模变大，应用需求越来越复杂，管理灾难便出现了。

例如，一开始你只在一台服务器上部署了一个博客应用服务，后来，访问人数越来越多，一台服务器不够用了，于是又买了几台服务器，部署了多个博客服务的实例。随后，你又开发了一个外卖服务，又开发了一个支付服务。随着服务越来越多，需求也越来越复杂，有的服务是只想内网访问，有的服务需要超大内存才能跑。于是，你开始在不同的服务器上登录，执行手动操作管理应用。这样的操作不仅繁琐低效，而且非常容易出错。

于是，容器编排部署技术应运而生，其代表性技术便是K8S。K8S 是一个开源的，用于管理云平台中多个主机上的容器化的应用，Kubernetes 的目标是让部署容器化的应用简单并且高效（powerful），Kubernetes 提供了应用部署，规划，更新，维护的一种机制。也就是说，K8S是一项基于Docker容器化技术之上开发的技术。

这里可能有人就要说了，docker compose不也可以用于容器编排吗？为什么不直接使用docker compose呢？

这主要是因为docker compose主要面向单机环境，无法跨多主机分布式部署，同时它也不具备高可用性、故障自动转移或服务发现机制。而后面这三者恰恰是大厂最看重的三项特性。

二、Kubernetes 集群架构与组件

直接上图。
操作K8S主要由两种方法，一是通过kubectl命令行工具，二是通过Dashboard。其中一是K8S官方提供的方式，二是各大第三方的厂商所开发的。在K8S整体架构上来看，我们是通过这两者，操作控制面板Master中的各个组件，进而操作节点Node中的各个组件。
在这里插入图片描述

1.控制面板组件（Master）

在这里插入图片描述

a. kube-apiserver

Kubernetes API 服务器的主要实现是 kube-apiserver，用户通过UI或CLI对K8S的API进行访问时，会经过kube-apiserver接受请求。 kube-apiserver 设计上考虑了水平扩缩，也就是说，它可通过部署多个实例来进行扩缩，并在这些实例之间平衡流量。

b. kube-controller-manager

在K8S中，一切皆资源，kube-controller-manager便是通过控制这些控制器去控制这些资源。从逻辑上讲，每个控制器都是一个单独的进程，但是为了降低复杂性，它们都被编译到同一个可执行文件，并在同一个进程中运行。

这些控制器包括：
节点控制器（Node Controller）：负责在节点出现故障时进行通知和响应。
任务控制器（Job Controller）：监测代表一次性任务的 Job 对象，然后创建 Pods 来运行这些任务直至完成。
端点分片控制器（EndpointSlice controller）：填充端点分片（EndpointSlice）对象（以提供 Service 和 Pod 之间的链接）。
服务账号控制器（ServiceAccount controller）：为新的命名空间创建默认的服务账号（ServiceAccount）。

c. cloud-controller-manager

kube-controller-manager控制本地资源，cloud-controller-manager控制云端资源，负责与各类第三方云平台进行对接。

d. kube-scheduler

kube-scheduler 负责资源的调度，按照预定的调度策略将 Pod 调度到相应的机器上。（后文在核心概念篇会详细介绍 Pod）

e. etcd

etcd 是一个键值类型存储的分布式数据库，可以理解为 K8S 的数据库，提供了 Raft 算法实现的高可用性能，老版本是基于内存，新版本是基于持久化存储。详细可以访问 https://etcd.io/docs/

2.节点组件（Node）

a. kubelet

kubelet 负责维护 Pod 的生命周期，同时也负责存储Volume（CVI）和网络（CNI）的管理；

b. kube-proxy

kube-proxy 负责为 Service 提供 cluster 内部的服务发现和负载均衡；

c. container runtime

container runtime 负责提供容器时运行环境，docker、containerd、CRI-O。从这也可以看出，K8S其实并不一定非要用 docker。

d. pod

Node下可能会有多个 pod，而一个 pod 下可能会有多个容器。kubelet 、 kube-proxy 、 container runtime、 pod构成了节点组件 Node。

3.附加组件

a. kube-dns

kube-dns 负责为整个集群提供 DNS 服务

b. Ingress Controller

Ingress Controller 为服务提供外网入口

c. Prometheus

Prometheus 提供资源监控

d. Federation

Federation 提供跨可用区的集群

e. Fluentd-elasticsearch

Fluentd-elasticsearch 提供集群日志采集、存储与查询

4. 分层架构

官方图示
在这里插入图片描述

a. 生态系统层

在接口层之上的庞大容器集群管理调度的生态系统，可以划分为两个范畴：
Kubernetes 外部：日志、监控、配置管理、CI、CD、Workflow、FaaS、OTS 应用、ChatOps 等
Kubernetes 内部：CRI、CNI、CVI、镜像仓库、Cloud Provider、集群自身的配置和管理等