0.前言

首先要说的一点：这篇文章不是什么教程，单纯是自己学习的笔记，如果有错误望各位大佬指正。

1. Kubernetes

1.1 什么是Kubernetes

Kubernetes是一个开源容器协调器，由Google开发，用于管理在容器环境中运行的应用程序。

1.2 为什么要使用容器

我们在选择的时候主要是在虚拟机和容器之间选择，这两者具体的区别很多，但他们都有着类似的使命：对应用程序及其关联性进行隔离，从而构建起一套能够随处运行的自容纳单元。
  主要区别，在于：虚拟机多了一层Guest OS，虚拟机的Hypervisor会对硬件资源也进行虚拟化，而Container会直接使用宿主机的硬件资源。
  如下图的左图的虚拟机架构中，我们的主机虚拟化了3个VM，每个VM又有自己的Guest OS，这个就意味着需要模拟3个操作系统。对比右图的容器架构中，我们的3个容器都在一个操作系统上运行，并不需要模拟任何操作系统。所以相对左图我们会消耗更少的资源，并达到跟虚拟机架构中等同的效果。

image.png

简而言之，容器小巧，灵活且可移植，因此它们可以帮助您快速部署和管理应用程序，并根据需求进行扩展或缩小。在容器部署模型中，应用程序不依赖于特定的主机，因此可以以更有效的方式跨可用资源分布它们。这种环境非常适合部署微服务。

1.3 什么是微服务

微服务是一种架构风格，它将应用程序分解为一组松散耦合的服务，这些服务可以是细粒度和轻量级的。这种风格促进了模块化，并行开发，持续交付以及许多其他好处。

1.4 微服务与kubernates的关系

拥有许多在容器上运行的微服务可能会变得难以管理，因此这就是Kubernetes的用武之地：Kubernetes自动化应用程序容器的部署，扩展和操作。并提供工具和API来管理容器上的生产工作负载。它还支持多个云和裸机环境，并且是为可扩展性而设计的，因此有一个丰富的插件生态系统可以扩展其功能。有用于调度，存储，网络等的插件。

2. Kubernetes集群架构

image.png

从上图可以看出Kubernetes架构基于Cluster的概念。集群由一个或多个称为Node的虚拟机组成。每个Node代表一个计算主机，我们可以在其中部署，运行和管理容器化应用程序。

2.1 Master节点

Node节点由Kubernetes的Master节点管理，Master节点控制和监视集群中的所有Kubernetes资源。 kube-scheduler服务决定部署应用程序的位置，同时考虑集群中的部署要求和可用容量。Kubernetes主要由以下几个核心组件组成：

• etcd:
  用于 Kubernetes 的后端存储。所有集群数据都存储在此处，始终为 Kubernetes 集群的 etcd 数据提供备份计划；
• apiserver:
  提供了资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制；
• controller manager:
  负责维护集群的状态，比如故障检测、自动扩展、滚动更新等；
• scheduler:
  监视没有分配节点的新创建的 Pod，选择一个节点供他们运行。

2.2 Node节点

Node节点在 Kubernetes 主节点的控制下执行被分配的任务。Kubernetes的node节点主要由以下几个核心组件组成：

• kubelet:
  是一个代理，它在集群中的每个节点上运行，与主服务器通信，并管理节点上的活动和资源，例如通过Docker运行Pod容器。它负责维护容器的生命周期，同时也负责Volume（CVI）和网络（CNI）的管理；
• kube-proxy:
  负责为Service提供cluster内部的服务发现和负载均衡；
• Pod:
  Kubernetes创建一个Pod来托管应用程序实例。 Pod可以包括一个或多个应用程序Container和一些共享资源，例如存储，网络信息等。 Pod中的Container共享IP地址和端口空间，始终位于同一位置并共同调度，并在同一节点上的共享上下文中运行。

由于可以在向上或向下扩展或进行滚动更新的过程中动态创建和销毁Pod，因此Pod IP地址可能会随着时间的推移而发生变化。如果某些Pod为其他Pod提供功能，并且地址发生变化，他们如何相互跟踪？

答案是Service！

2.3 Service

Service是一种策略，它将一组Pod定义为端点，以及用于访问它们。当Service中的Pod集发生变化时，Kubernetes可以更新端点。

与部署一样，我们可以在YAML文件中定义服务。 Kubernetes为服务分配“集群IP地址”，kube-proxy使用此地址来适当地路由请求。

具体的在下一节介绍。

3. Kubernetes资源

Kubernetes资源之间的关系：

• 用户通过 kubectl 创建 Deployment。
• Deployment 创建 ReplicaSet。
• ReplicaSet 创建 Pod。

image.png

3.1 Deployments

Deployments是kubernetes中的一种控制器，是比ReplicaSet更高级的概念，它最重的特性是支持对pod与ReplicaSet的声明式升级，声明式升级比其它方式的升级更安全可靠。需要注意的是用户不应该手动管理被Deployments创建的ReplicaSet。

以下是几种典型的Deployments使用案例：

• Create a Deployment to rollout a ReplicaSet. The ReplicaSet creates Pods in the background. Check the status of the rollout to see if it succeeds or not.
• Declare the new state of the Pods by updating the PodTemplateSpec of the Deployment. A new ReplicaSet is created and the Deployment manages moving the Pods from the old + **ReplicaSet to the new one at a controlled rate. Each new ReplicaSet updates the revision of the Deployment.
• Rollback to an earlier Deployment revision if the current state of the Deployment is not stable. Each rollback updates the revision of the Deployment.
• Scale up the Deployment to facilitate more load.
• Pause the Deployment to apply multiple fixes to its PodTemplateSpec and then resume it to start a new rollout.
• Use the status of the Deployment as an indicator that a rollout has stuck.
• Clean up older ReplicaSets that you don’t need anymore.

3.2 ReplicaSets

用户创建指定数量的pod副本数量，确保pod副本数量符合预期状态，并且支持滚动式自动扩容和缩容功能。

ReplicaSet主要三个组件组成：

• 用户期望的pod副本数量
• 标签选择器，判断哪个pod归自己管理
• 当现存的pod数量不足，会根据pod资源模板进行新建

帮助用户管理无状态的pod资源，精确反应用户定义的目标数量，但是RelicaSet不是直接使用的控制器，而是使用Deployment。

3.3 Pods

Pod是Kubernetes最基本的操作单元，包含一个或多个紧密相关的容器，一个Pod可以被一个容器化的环境看作应用层的“逻辑宿主机”；一个Pod中的多个容器应用通常是紧密耦合的，Pod在Node上被创建、启动或者销毁；每个Pod里运行着一个特殊的被称之为Pause的容器，其他容器则为业务容器，这些业务容器共享Pause容器的网络栈和Volume挂载卷，因此他们之间通信和数据交换更为高效，在设计时我们可以充分利用这一特性将一组密切相关的服务进程放入同一个Pod中。

同一个Pod里的容器之间仅需通过localhost就能互相通信。

image.png

Pod的生命周期通过Replication Controller来管理；通过模板进行定义，然后分配到一个Node上运行，在Pod所包含容器运行结束后，Pod结束。

&Kubernetes为Pod设计了一套独特的网络配置，包括：为每个Pod分配一个IP地址，使用Pod名作为容器间通信的主机名等。

3.4 Services

如前所述，Service是一种对象抽象，它定义了访问Pod或Pod集的策略。 Kubernetes Services支持协议的TCP和UDP。默认值为TCP。

在Kubernetes中，Kubernetes有4种外部访问方式，Service types确定服务的部署方式及其行为方式：

• ClusterIP：
  将服务内部暴露给Cluster IP地址上。此类型是默认类型。
• NodePort：在NodePort指定的端口上的每个集群节点的IP地址上公开服务。将自动创建关联的ClusterIP服务。
  该服务可通过<任何节点IP>：<NodePort>访问，也可通过ClusterIP在内部访问，并可指定或自动分配。
• LoadBalancer：
  使用云提供商的负载均衡器在外部公开服务。创建关联的NodePort和ClusterIP服务。
• ExternalName：
  通过返回带有值的CNAME记录将服务映射到externalName字段。没有配置任何类型的代理。

集群外部访问Pod或Service的方法？

大多数组织不希望将敏感数据直接暴露给Internet，通常，可以为前端（BFF）或API网关构建后端，以控制对后端资源的访问。然后，请求通过Kubernetes内部网络，可由LoadBalancer，Ingress或NodePort处理。NodePort不适用生产环境，所以只有LoadBalancer，Ingress可供选择，他们两个的优缺点如下所示：

image.png

3.5 Volumn

Volumn是具有生命周期，并且可以比容器更长，从而在容器重启之间保留数据。 Kubernetes Volumn是可由Pod中的容器访问的目录。

• **emptyDir：
  **将Pod分配给节点时创建emptyDir实例。 Pod在该节点上运行时存在emptyDir。如其名称所示，它最初是空的。当出于任何原因从节点中删除Pod时，将永久删除emptyDir中的数据。

• **NFS：
  **允许将NFS（网络文件系统）共享安装到Pod中的volumn。与删除Pod时删除的emptyDir不同，NFSvolumn的内容将被保留，并且将卸载Volume。 NFS volumn可以预先填充数据，并且可以在Pod之间移动数据。 NFS可以由多个编写器同时安装。

如下图所示，Kubernetes Volumn主要解决了以下问题：

• Pods（容器）是短暂的。如果容器崩溃，数据将丢失。
• Pod中运行多个容器，这些容器可能需要共享数据。
• Docker也有Volume的概念，但它只是磁盘或容器中的目录。

image.png

名词解释：

• PV（PersistentVolume）：
  集群中已由管理员配置的一段网络存储。 集群中的资源就像一个节点是一个集群资源。 PV是诸如卷之类的卷插件，但是具有独立于使用PV的任何单个pod的生命周期。 该API对象捕获存储的实现细节，即NFS，iSCSI或云提供商特定的存储系统。

• PVC（PersistentVolumeClaim）：
  是用户存储的请求。 它类似于pod。Pod消耗节点资源，PVC消耗存储资源。 pod可以请求特定级别的资源（CPU和内存）。 权限要求可以请求特定的大小和访问模式。

• StorageClass：
  虽然PersistentVolumeClaims允许用户使用抽象存储资源，但是用户需要具有不同属性（如性能）的PersistentVolumes，用于不同的问题。 群集管理员需要能够提供多种不同于PersistentVolumes的PersistentVolumes，而不仅仅是大小和访问模式，而不会使用户了解这些卷的实现细节。 对于这些需求，存在StorageClass资源。
    StorageClass为管理员提供了一种描述他们提供的存储的“类”的方法。 不同的类可能映射到服务质量级别，或备份策略，或者由群集管理员确定的任意策略。 Kubernetes本身对于什么类别代表是不言而喻的。 这个概念有时在其他存储系统中称为“配置文件”

PV是集群中的资源。 PVC是对这些资源的请求，也是对资源的索赔检查。 PV和PVC之间的相互作用遵循这个生命周期:

Provisioning ——-> Binding ——–>Using——>Releasing——>Recycling

Provisioning
这里有两种PV的提供方式: 静态或者动态

静态：集群管理员创建多个PV。它们包含真实存储的详细信息，可供用户使用。它们存在于Kubernetes API中，可供使用。
动态：当管理员创建的静态PV都不匹配用户的PVC时，集群可能会尝试为PVC动态配置volumn。此配置基于StorageClasses。要进行动态配置，管理员必须创建和配置存储类，并且PVC必须请求该存储类。

就先写这么多，to be continue...