1  Kubernetes 概述

1.1 什么是 K8s

• Kubernetes 是一个快速发展的平台，用于管理基于容器的应用程序及其相关网络和存储组件。

• Kubernetes 重点关注应用程序工作负载，而不是底层基础结构组件。

• Kubernetes 提供了一种声明性的部署方法，由一组针对管理操作的强大 API 提供支持。

• 开发人员可构建和运行可移植的、基于微服务的现代应用程序，从而使用 Kubernetes 安排和管理这些应用程序组件的可用性。

1.2 为什么使用 K8s

• 传统部署👉早期，组织在物理服务器上运行应用程序。无法为物理服务器中的应用程序定义资源边界，这会导致资源分配问题。例如，如果多个应用程序在物理服务器上运行，则可能存在一个应用程序占用大部分资源的情况，因此，其他应用程序的性能会不佳，并且组织维护许多物理服务器的成本很高。

• 虚拟化部署👉引入了虚拟化后，它允许在单个物理服务器的 CPU 上运行多个虚拟机 （VM）。虚拟机为应用程序提供隔离，并保证一定程度的安全（因为一个应用程序的信息不能被另一个应用程序自由访问）。虚拟化可以更好地利用物理服务器中的资源，并允许更好的可扩展性，因为可以轻松添加或更新应用程序，降低硬件成本等等。通过虚拟化，您可以将一组物理资源呈现为一次性虚拟机群集。每个 VM 都是一个完整的计算机，在虚拟化硬件之上运行所有组件，包括其自己的操作系统。

• 容器部署👉容器类似于 VM，但它们具有宽松的隔离属性，可在应用程序之间共享操作系统 （OS）。因此，容器被认为是轻量级的虚拟机。由于它们与底层基础架构分离，因此它们可以跨云和操作系统分发进行移植。容器之所以变得流行，相比虚拟机它的优势在于：敏捷的应用程序创建和部署：与使用 VM 映像相比，容器映像创建的易用性和效率更高。持续开发、集成和部署：通过快速高效的回滚（由于映像不可变性），提供可靠且频繁的容器映像构建和部署。开发和运营关注点分离：在构建/发布时而不是部署时创建应用程序容器映像，从而将应用程序与基础架构分离。可观察性：不仅显示操作系统级别的信息和指标，还显示应用程序运行状况和其他信号。开发、测试和生产中的环境一致性：在笔记本电脑上运行与在云中运行相同。云和操作系统分发可移植性：在 Ubuntu、RHEL、CoreOS、本地、主要公共云和其他任何地方运行。以应用程序为中心的管理：将抽象级别从在虚拟硬件上运行操作系统提高到使用逻辑资源在操作系统上运行应用程序。松散耦合、分布式、弹性、解放的微服务：应用程序被分解成更小、独立的部分，可以动态部署和管理，而不是在一台大型单一用途机器上运行的整体堆栈。资源隔离：可预测的应用程序性能。资源利用率：高效率和高密度

2  K8s 架构

2.1 架构图

K8s架构

2.1.1 Control Plane

kube-apiserver

API 服务器是 Kubernetes 控制面板的组件， 该组件负责公开了 Kubernetes API，负责处理接受请求的工作。 API 服务器是 Kubernetes 控制平面的前端。

Kubernetes API 服务器的主要实现是 kube-apiserver。 kube-apiserver 设计上考虑了水平扩缩，也就是说，它可通过部署多个实例来进行扩缩。 你可以运行 kube-apiserver 的多个实例，并在这些实例之间平衡流量。

etcd

etcd 是兼顾一致性与高可用性的键值数据库，可以作为保存 Kubernetes 所有集群数据的后台数据库。

kube-scheduler

kube-scheduler 是控制平面的组件， 负责监视新创建的、未指定运行节点（node）的 Pods， 并选择节点来让 Pod 在上面运行。

调度决策考虑的因素包括单个 Pod 及 Pods 集合的资源需求、软硬件及策略约束、 亲和性及反亲和性规范、数据位置、工作负载间的干扰及最后时限。

kube-controller-manager 

从逻辑上讲， 每个控制器都是一个单独的进程， 但是为了降低复杂性，它们都被编译到同一个可执行文件，并在同一个进程中运行。

这些控制器包括：

• 节点控制器（Node Controller）：负责在节点出现故障时进行通知和响应

• 任务控制器（Job Controller）：监测代表一次性任务的 Job 对象，然后创建 Pods 来运行这些任务直至完成

• 端点控制器（Endpoints Controller）：填充端点（Endpoints）对象（即加入 Service 与 Pod）

• 服务帐户和令牌控制器（Service Account & Token Controllers）：为新的命名空间创建默认帐户和 API 访问令牌

2.1 Node 组件

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

Node架构

kubelet

kubelet 会在集群中每个节点上运行。 它保证容器都运行在 Pod 中。

kubelet 直接跟容器引擎交互 实现容器的生命周期管理， 接收一组通过各类机制提供给它的 PodSpecs， 确保这些 PodSpecs 中描述的容器处于运行状态且健康。 kubelet 不会管理不是由 Kubernetes 创建的容器。

kube-proxy

kube-proxy 是集群中每个节点（node）所上运行的网络代理， 实现 Kubernetes 服务（Service） 概念的一部分。

kube-proxy 维护节点上的一些网络规则， 这些网络规则会允许从集群内部或外部的网络会话与 Pod 进行网络通信。

如果操作系统提供了可用的数据包过滤层，则 kube-proxy 会通过它来实现网络规则。 否则，kube-proxy 仅做流量转发。

容器运行时（Container Runtime）

容器运行环境是负责运行容器的软件。

Kubernetes 支持许多容器运行环境，例如 Docker、 containerd、 CRI-O 以及 Kubernetes CRI (容器运行环境接口) 的其他任何实现。

Pod

Pod 是 kubernetes 中最小的资源管理组件，Pod 也是最小化运行容器化应用的资源对象。一个 Pod 代表着集群中运行的一个进程。kubernetes 中其 他大多数组件都是围绕着 Pod 来进行支撑和扩展 Pod 功能的，例如，用于管理 Pod 运行的 StatefulSet 和 Deployment 等控制器对象，用于暴露 Pod 应用的 Service 和 Ingress 对象，为 pod 提供存储的 PersistentVolume 存储资源对象等。

• 最小的调度以及资源单元

• 由一个或者多个容器组成

• 定义容器运行的方式

• 提供容器共享的运行环境

Pod 资源中针对各容器提供网络命令空间等共享机制的是底层基础容器 pause,基础容器(父容器) pause 就是为了管理 Pod 容器间的共享操作，这个父容器需要能够准确地知道如何去创建共享运行环境的容器，还能管理这些容器的生命周期。为了实现这个父容器的构想，kubernetes 中，用 pause 容器来作为一个 Pod 中所有容器的父容器。

• 网络

每个 Pod 都会被分配一个唯一的 IP 地址。Pod 中的所 有容器共享网络空间，包括 IP 地址和端口。Pod 内 部的容器可以使用 localhost 互相通信。Pod 中的容器与外界通信时，必须分配共享网络资源(例如使用宿主机的端口映射)

• 存储

Pod 可以指定多个共享的 Volume。Pod 中的所有容器都可以访问共享的 Volume，Volume 也可以用来持久化 Pod 中的存储资源，以防容器重启后文件丢失。

2.3 其他插件

CoreDNS

可以为集群中的 SVC 创建一个域名 IP 的对应关系解析。

Dashboard

给 K8s 集群提供一个 B/S 结构访问体系。

IngressController

官方实现了四层代理 Ingress 可以实现七层代理。

Prometheus

提供 K8s 集群的监控能力。

Federation

提供一个可以跨集群中心多 K8s 统一管理功能。

ELK

提供 K8s 集群日志统一分析介入平台。

3 相关工具(Windows)

3.1 Kubectl

3.2 Minikube 

3.3 。。。

4 基础应用

4.1 集群体系结构

Kubernetes 协调一个高可用计算机集群，每个计算机作为独立单元互相连接工作。 Kubernetes 中的抽象允许你将容器化的应用部署到集群，而无需将它们绑定到某个特定的独立计算机。为了使用这种新的部署模型，应用需要以将应用与单个主机分离的方式打包：它们需要被容器化。与过去的那种应用直接以包的方式深度与主机集成的部署模型相比，容器化应用更灵活、更可用。 Kubernetes 以更高效的方式跨集群自动分发和调度应用容器。 Kubernetes 是一个开源平台，并且可应用于生产环境。

一个 Kubernetes 集群包含两种类型的资源:

• Master 调度整个集群

• Nodes 负责运行应用

Master 负责管理整个集群。 Master 协调集群中的所有活动，例如调度应用、维护应用的所需状态、应用扩容以及推出新的更新。

Node 是一个虚拟机或者物理机，它在 Kubernetes 集群中充当工作机器的角色 每个 Node 都有 Kubelet , 它管理 Node 而且是 Node 与 Master 通信的代理。 Node 还应该具有用于​​处理容器操作的工具，例如 Docker 或 rkt 。处理生产级流量的 Kubernetes 集群至少应具有三个 Node，因为如果一个 Node 出现故障其对应的 etcd 成员和控制平面实例都会丢失，并且冗余会受到影响。 你可以通过添加更多控制平面节点来降低这种风险 。

Master 管理集群，Node 用于托管正在运行的应用。

在 Kubernetes 上部署应用时，你告诉 Master 启动应用容器。 Master 就编排容器在集群的 Node 上运行。 Node 使用 Master 暴露的 Kubernetes API 与 Master 通信。终端用户也可以使用 Kubernetes API 与集群交互。

Kubernetes 既可以部署在物理机上也可以部署在虚拟机上。你可以使用 Minikube 开始部署 Kubernetes 集群。 Minikube 是一种轻量级的 Kubernetes 实现，可在本地计算机上创建 VM 并部署仅包含一个节点的简单集群。 Minikube 可用于 Linux ， macOS 和 Windows 系统。Minikube CLI 提供了用于引导集群工作的多种操作，包括启动、停止、查看状态和删除。在本教程里，你可以使用预装有 Minikube 的在线终端进行体验。

4.2 创建集群

• minikube start

--集群启动PS C:\Windows\system32> minikube start --kubernetes-version=v1.23.8--查看状态PS C:\Windows\system32> minikube status--打开看板PS C:\Windows\system32> minikube dashboard

minikube start

Dashboard

说明：这里之所以指定版本，是因为 1.24（默认拉取最新版本）这个版本在本地启动时存在诸多问题。

1、kubelate 生成失败

error-info

2、apiserver 启动失败

error-info

• kubectl cluster-info

• kubectl get nodes

cluster-info

4.3 部署应用

4.3.1 创建.NetCore 程序

[以笔者本地程序为例，详见Docker入坑篇]

创建名为 hello-docker 的程序，然后将程序发布到镜像仓库（Kubernetes 默认镜像仓库为 Docker Hub），用于 K8s 应用部署时的镜像拉取。

 --CD到Dockerfile所在目录，执行PS命令，生成imagePS D:\bin1943\dotnet-projects\hello-docker> docker build -t hello-docker .--给镜像打上tag，并发布到dockerhub指定仓库hello-dockerPS D:\bin1943\dotnet-projects\hello-docker> docker push binjiang2020/hello-docker:0713

Docker Hub

4.3.2 发布应用

1、用 Kubectl 命令式访问

• 创建 Deloyment

 --这里用的镜像正是上一步在发布在DockerHub中的：binjiang2020/hello-docker:0713 <PowerShell> kubectl create deployment hello-kube --image=binjiang2020/hello-docker:0713

Dashboard/Deployment

• 暴露 NodePort

--暴露服务端口给外部访问，注意这里的port是容器监听端口（在Dockfile指定的） <PowerShell>  kubectl expose deployment hello-kube --type=NodePort --port=80

• 访问 Service

<PowerShell>  minikube service hello-kube

minikube service

2、通过 yaml 文件申明式创建