概念

· 容器运行时

容器运行时负责运行容器的软件。你需要在K8S集群内每个节点上安装一个 容器运行时 以使 Pod 可以运行在上面。 Kubernetes 中几个常见的容器运行时。

1、containerd
2、CRI-O
3、Docker Engine
4、Mirantis Container Runtime

· dockershim

v1.24 之前的 Kubernetes 版本直接集成了 Docker Engine 的一个组件，名为 dockershim。
自 1.24 版起，Dockershim 已从 Kubernetes 项目中移除。Kubernetes 1.24要求你使用符合容器运行时接口（CRI）的运行时。

· cgroup 驱动

在 Linux 上，控制组（CGroup）用于限制分配给进程的资源。
kubelet 和底层容器运行时都需要对接控制组来强制执行为Pod和容器管理资源并为诸如 CPU、内存这类资源设置请求和限制。
若要对接控制组，kubelet和容器运行时需要使用一个 cgroup 驱动。 关键的一点是 kubelet 和容器运行时需使用相同的 cgroup 驱动并且采用相同的配置。
可用的 cgroup 驱动有两个：

1、cgroupfs
2、systemd

· 高可用拓扑选项

配置高可用（HA）Kubernetes 集群拓扑的两个选项。两种选项都需要负载均衡。

1、使用堆叠（stacked）控制平面节点，其中 etcd 节点与控制平面节点共存
2、使用外部 etcd 节点，其中 etcd 在与控制平面不同的节点上运行

· Kubernetes 集群负载均衡实现方式

1、keepalived and haproxy
2、kube-vip
3、Bootstrap the cluster

· Kubernetes 资源和对象

Kubernetes 中的所有内容都被抽象为“资源”，如 Pod、Service、Node 等都是资源。“对象”就是“资源”的实例，是持久化的实体。如某个具体的 Pod、某个具体的 Node。Kubernetes 使用这些实体去表示整个集群的状态。
  对象的创建、删除、修改都是通过 “Kubernetes API”，也就是 “Api Server” 组件提供的 API 接口，这些是 RESTful 风格的 Api，与 k8s 的“万物皆对象”理念相符。命令行工具 “kubectl”，实际上也是调用 kubernetes api。
  K8s 中的资源类别有很多种，kubectl 可以通过配置文件来创建这些 “对象”，配置文件更像是描述对象“属性”的文件，配置文件格式可以是 “JSON” 或 “YAML”，常用 “YAML”。

· 对象的状态

在.yaml 格式的文件中，spec字段描述对象的期望状态，status字段描述对象的当前状态。

期望状态：

Kubernetes 对象是“目标性记录” —— 一旦创建该对象，Kubernetes 系统将不断工作以确保该对象存在。
通过创建对象，你就是在告知 Kubernetes 系统，你想要的集群工作负载状态看起来应是什么样子的，
这就是 Kubernetes 集群所谓的 期望状态（Desired State）。

当前状态：

它是由 Kubernetes 系统和组件设置并更新的。 在任何时刻，
Kubernetes 控制平面 都一直都在积极地管理着对象的实际状态，以使之达成期望状态。

· Kubernetes 对象管理

kubectl 命令行工具支持多种不同的方式来创建和管理 Kubernetes 对象。

· Kubernetes 对象管理

Namespace：

名称空间也称为虚拟集群，逻辑上对资源进行分组以及隔离。

Pod：

Pod是Kubernetes的最小工作单元。每个Pod包含一个或多个容器。
Pod中的容器会作为一个整体被Master调度到一个Node上运行。分为自主性Pod和被控制器管理的Pod。
在Kubernetes 中，每个Pod会有自己独立的内部动态IP，在Pod新建或重启时会重新分配新的IP。

Controller：

Pod控制器是用于管理pod的中间层，确保pod资源始终符合预期的状态，pod的资源出现故障时，
会尝试进行重启，当根据重启策略无效，则会重新新建pod的资源。pod控制器确保pod运行不出问题，
出问题后自动恢复。

Service：

我们可以通过pod的ip来访问应用程序，但是pod的ip地址不是固定的，
这也就意味着不方便直接采用pod的ip对服务进行访问。为了解决这个问题，kubernetes提供了Service资源，
Service会对提供同一个服务的多个pod进行聚合，并且提供一个统一的入口地址。
通过访问Service的地址就能访问到后面的pod服务。

Selector：

它是根据Label对符合条件的资源过滤的一种机制，
控制器对Pod的管理以及service对Pod的选择都是通过标签选择器筛选。

· 容器

镜像：

容器镜像（Image）所承载的是封装了应用程序及其所有软件依赖的二进制数据。 
容器镜像是可执行的软件包，可以单独运行；

镜像拉取策略：

IfNotPresent
	只有当镜像在本地不存在时才会拉取。
Always
	每当 kubelet 启动一个容器时，kubelet 会查询容器的镜像仓库， 将名称解析为一个镜像摘要。 
	如果 kubelet 有一个容器镜像，并且对应的摘要已在本地缓存，kubelet 就会使用其缓存的镜像；
	否则，kubelet 就会使用解析后的摘要拉取镜像，并使用该镜像来启动容器。
Never
	Kubelet 不会尝试获取镜像。如果镜像已经以某种方式存在本地， kubelet 会尝试启动容器；
	否则，会启动失败。 更多细节见提前拉取镜像。

· 工作负载资源

Deployments

一个 Deployment 为 Pod 和 ReplicaSet 提供声明式的更新能力。
你负责描述 Deployment 中的 目标状态，而 Deployment 控制器以受控速率更改实际状态， 使其变为期望状态。
你可以定义 Deployment 以创建新的 ReplicaSet，或删除现有 Deployment， 并通过新的 Deployment 收养其资源。
当你创建一个 Deployment 控制器后会自动创建一个 ReplicaSet控制器。

ReplicaSet

ReplicaSet 的目的是维护一组在任何时候都处于运行状态的 Pod 副本的稳定集合。 
因此，它通常用来保证给定数量的、完全相同的 Pod 的可用性。

*Deployments与ReplicaSet：*

ReplicaSet 确保任何时间都有指定数量的 Pod 副本在运行。 然而，Deployment 是一个更高级的概念，
它管理 ReplicaSet，并向 Pod 提供声明式的更新以及许多其他有用的功能。 
因此，我们建议使用 Deployment 而不是直接使用 ReplicaSet， 除非你需要自定义更新业务流程或根本不需要更新。
这实际上意味着，你可能永远不需要操作 ReplicaSet 对象：而是使用 Deployment，并在 spec 部分定义你的应用。

StatefulSet

StatefulSet 是用来管理有状态应用的工作负载 API 对象。
StatefulSet 用来管理某 Pod 集合的部署和扩缩， 并为这些 Pod 提供持久存储和持久标识符。

DaemonSet

DaemonSet 确保全部（或者某些）节点上运行一个 Pod 的副本。 
当有节点加入集群时， 也会为他们新增一个 Pod 。 当有节点从集群移除时，这些 Pod 也会被回收。
删除 DaemonSet 将会删除它创建的所有 Pod。

Job

Job 会创建一个或者多个 Pod，并将继续重试 Pod 的执行，直到指定数量的 Pod 成功终止。 
随着 Pod 成功结束，Job 跟踪记录成功完成的 Pod 个数。 
当数量达到指定的成功个数阈值时，任务（即 Job）结束。 
删除 Job 的操作会清除所创建的全部 Pod。
挂起 Job 的操作会删除 Job 的所有活跃 Pod，直到 Job 被再次恢复执行。

CronJob

CronJob 创建基于时隔重复调度的 Jobs。
一个 CronJob 对象就像 crontab (cron table) 文件中的一行。 
它用 Cron 格式进行编写， 并周期性地在给定的调度时间执行 Job。

ReplicationController

ReplicationController 确保在任何时候都有特定数量的 Pod 副本处于运行状态。 
换句话说，ReplicationController 确保一个 Pod 或一组同类的 Pod 总是可用的。

· 服务（Service）

介绍：

将运行在一组 Pods 上的应用程序公开为网络服务的抽象方法。
在 Kubernetes 集群中，每个 Node 运行一个 kube-proxy 进程。
kube-proxy 负责为 Service 实现了一种 VIP（虚拟 IP）的形式，而不是 ExternalName 的形式。

工作模式：

 userspace 代理模式 
 iptables 代理模式
 IPVS 代理模式

发布服务（服务类型)：

对一些应用的某些部分（如前端），可能希望将其暴露给 Kubernetes 集群外部的 IP 地址。
Kubernetes ServiceTypes 允许指定你所需要的 Service 类型，默认是 ClusterIP。

Type 的取值以及行为如下：

ClusterIP：
	通过集群的内部 IP 暴露服务，选择该值时服务只能够在集群内部访问。 这也是默认的 ServiceType。

NodePort：
	通过每个节点上的 IP 和静态端口（NodePort）暴露服务。
	NodePort 服务会路由到自动创建的 ClusterIP 服务。 通过请求 <节点 IP>:<节点端口>，
	你可以从集群的外部访问一个 NodePort 服务。

LoadBalancer：
	使用云提供商的负载均衡器向外部暴露服务。 
	外部负载均衡器可以将流量路由到自动创建的 NodePort 服务和 ClusterIP 服务上。

ExternalName：
	通过返回 CNAME 和对应值，可以将服务映射到 externalName 字段的内容（例如，foo.bar.example.com）。 
	无需创建任何类型代理。

· Ingress

Ingress 是对集群中服务的外部访问进行管理的 API 对象，典型的访问方式是 HTTP。
Ingress 可以提供负载均衡、SSL 终结和基于名称的虚拟托管。
Ingress 可为 Service 提供外部可访问的 URL、负载均衡流量、终止 SSL/TLS，以及基于名称的虚拟托管。
Ingress 控制器 通常负责通过负载均衡器来实现 Ingress，尽管它也可以配置边缘路由器或其他前端来帮助处理流量。

· Ingress 控制器

为了让 Ingress 资源工作，集群必须有一个正在运行的 Ingress 控制器。
与作为 kube-controller-manager 可执行文件的一部分运行的其他类型的控制器不同， Ingress 控制器不是随集群自动启动的。 基于此页面，你可选择最适合你的集群的 ingress 控制器实现。
Kubernetes 作为一个项目，目前支持和维护 AWS、 GCE 和 Nginx Ingress 控制器。