2021-08-15

容器-k8s网页常见名词

文章目录

1. Gateway（我们使用mulesoft api platform）
2. K8S网页名词

Gateway（我们使用mulesoft api platform）

Mulesoft Anypoint Platform使组织能够在ERP系统，CRM系统和其他系统之间同步数据并自动化事务

在MuleSoft的最新Connectivity Benchmark 报告中，我们了解到，平均而言，组织使用900个应用程序，其中只有29％的应用程序进行了连接或集成。 例如，ERP系统中的库存数据，后端数据库中的产品信息，CRM系统中的客户和帐户数据，HCM解决方案中的HR数据，CPQ中的价格，此外，企业中还有大量用于消息传递、协作、报告等其他平台。

当企业尝试连接这些系统时，通常使用定制代码或点到点集成。这会变得脆弱，混乱，并且很难找到信息，而且APP与项目或底层端点紧密耦合。如果端点或业务需求发生任何变化，则整个APP或代码的主要部分需要重写。

这不仅是后台IT问题。它阻止了企业创新和建立新的客户体验。它会防止重用并延迟将来的项目。当一个移动APP出现了新的需求，需要提取完全相同的信息时，开发应用程序的开发人员就无法利用之前的项目所做的工作。随着时间的推移，改变变得昂贵或几乎不可能，使企业脱离了他们希望在市场中保持的任何竞争地位。

我们使用了他的policy, proxy。主要是policy好用。

K8S网页名词

cluster集群

cluster roles（集群角色控制）

基于角色的访问控制（Role-Based Access Control, 即”RBAC”）使用”rbac.authorization.k8s.io” API Group实现授权决策，允许管理员通过Kubernetes API动态配置策略。

Rules：规定一组可以在不同api group上的资源执行的规则（verbs） Role与ClusterRoles：都是包括一组规则（rules）两者不同在于，Role针对的是一个namespace中，ClusterRoles针对整个集群。

查看集群所有的clusterrole

kubectl get clusterrole -o yaml

查看某个clusterrole定义的资源权限详细信息

kubectl get clusterrolebinding

查看所有的clusterrolebinding

kubectl get clusterrolebinding -o yaml

命名空间namespace(多租户)

在一个Kubernetes集群中可以拥有多个命名空间，它们在逻辑上彼此隔离。他们可以为您和您的团队提供组织，安全甚至性能方面的帮助！

在Kubernetes中，Service通过一个DNS模式来暴露endpoint。这个模式类似：
<Service Name>.<Namespace Name>.svc.cluster.local
一般情况下，你只需要service的名称，DNS会自动解析到它的全地址。

在大的公司中，并不是每个人都认识其他人。团队间可能并不清楚各自的机能。微服务间通过service contract（例如gRPC）来通信，并通过service mesh（如istio）来协调通信。
试图在本地运行整个堆栈是不可能的。强烈建议使用Kubernetes-aware Continuous Delivery系统（例如，Spinnaker）。
此时，每个团队肯定需要自己的命名空间。每个团队甚至可以选择多个名称空间来运行其开发和生产环境。设置RBAC和ResourceQuotas也是一个好主意。多个集群开始显得很有意义，但可能不一定是必要的。

Nodes节点

通过将容器放入在节点（Node）上运行的 Pod 中来执行你的工作负载。节点可以是一个虚拟机或者物理机器，取决于所在的集群配置。每个节点包含运行 Pods 所需的服务；这些节点由控制面负责管理。

通常集群中会有若干个节点；而在一个学习用或者资源受限的环境中，你的集群中也可能只有一个节点。

节点上的组件包括 kubelet、容器运行时以及 kube-proxy。

从控制面（apiserver）到节点有两种主要的通信路径。第一种是从 apiserver 到集群中每个节点上运行的 kubelet 进程。第二种是从 apiserver 通过它的代理功能连接到任何节点、Pod 或者服务。

API 服务器到 kubelet

从 apiserver 到 kubelet 的连接用于：

获取 Pod 日志
挂接（通过 kubectl）到运行中的 Pod
提供 kubelet 的端口转发功能。

这些连接终止于 kubelet 的 HTTPS 末端。默认情况下，apiserver 不检查 kubelet 的服务证书。这使得此类连接容易受到中间人攻击，在非受信网络或公开网络上运行也是 不安全的。

为了对这个连接进行认证，使用 --kubelet-certificate-authority 标志给 apiserver 提供一个根证书包，用于 kubelet 的服务证书。

apiserver 到节点、Pod 和服务

从 apiserver 到节点、Pod 或服务的连接默认为纯 HTTP 方式，因此既没有认证，也没有加密。这些连接可通过给 API URL 中的节点、Pod 或服务名称添加前缀 https: 来运行在安全的 HTTPS 连接上。不过这些连接既不会验证 HTTPS 末端提供的证书，也不会提供客户端证书。因此，虽然连接是加密的，仍无法提供任何完整性保证。

persistent volumes（持久卷）

PersistentVolume 子系统为用户和管理员提供了一组 API，将存储如何供应的细节从其如何被使用中抽象出来。为了实现这点，我们引入了两个新的 API 资源：PersistentVolume 和 PersistentVolumeClaim。

持久卷（PersistentVolume，PV）是集群中的一块存储，可以由管理员事先供应，或者使用存储类（Storage Class）来动态供应。持久卷是集群资源，就像节点也是集群资源一样。PV 持久卷和普通的 Volume 一样，也是使用卷插件来实现的，只是它们拥有独立于任何使用 PV 的 Pod 的生命周期。此 API 对象中记述了存储的实现细节，无论其背后是 NFS、iSCSI 还是特定于云平台的存储系统。

持久卷申领（PersistentVolumeClaim，PVC）表达的是用户对存储的请求。概念上与 Pod 类似。 Pod 会耗用节点资源，而 PVC 申领会耗用 PV 资源。Pod 可以请求特定数量的资源（CPU 和内存）；同样 PVC 申领也可以请求特定的大小和访问模式（例如，可以要求 PV 卷能够以 ReadWriteOnce、ReadOnlyMany 或 ReadWriteMany 模式之一来挂载，参见访问模式）。

storage classes（存储类）

StorageClass 为管理员提供了描述存储 “类” 的方法。不同的类型可能会映射到不同的服务质量等级或备份策略，或是由集群管理员制定的任意策略。 Kubernetes 本身并不清楚各种类代表的什么。这个类的概念在其他存储系统中有时被称为 “配置文件”。

每个 StorageClass 都包含 provisioner、parameters 和 reclaimPolicy 字段，这些字段会在 StorageClass 需要动态分配 PersistentVolume 时会使用到。

管理员可以为没有申请绑定到特定 StorageClass 的 PVC 指定一个默认的存储类

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: standard
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp2
reclaimPolicy: Retain
allowVolumeExpansion: true
mountOptions:
  - debug
volumeBindingMode: Immediate

每个 StorageClass 都有一个制备器（Provisioner），用来决定使用哪个卷插件制备 PV。该字段必须指定。

由 StorageClass 动态创建的 PersistentVolume 会在类的 reclaimPolicy 字段中指定回收策略。

Namespace名字空间

可以搜索下面对应命名空间的dashboard

Workloads工作负载（运行的应用程序）

工作负载是在 Kubernetes 上运行的应用程序。

无论你的负载是单一组件还是由多个一同工作的组件构成，在 Kubernetes 中你可以在一组 Pods 中运行它。在 Kubernetes 中，Pod 代表的是集群上处于运行状态的一组容器。

为了让用户的日子略微好过一些，你并不需要直接管理每个 Pod。相反，你可以使用 负载资源 来替你管理一组 Pods。

Kubernetes 提供若干种内置的工作负载资源：

Deployment 和 ReplicaSet （替换原来的资源 ReplicationController）。 Deployment 很适合用来管理你的集群上的无状态应用，Deployment 中的所有 Pod 都是相互等价的，并且在需要的时候被换掉。
StatefulSet 让你能够运行一个或者多个以某种方式跟踪应用状态的 Pods。例如，如果你的负载会将数据作持久存储，你可以运行一个 StatefulSet，将每个 Pod 与某个 PersistentVolume 对应起来。你在 StatefulSet 中各个 Pod 内运行的代码可以将数据复制到同一 StatefulSet 中的其它 Pod 中以提高整体的服务可靠性。
DaemonSet 定义提供节点本地支撑设施的 Pods。这些 Pods 可能对于你的集群的运维是非常重要的，例如作为网络链接的辅助工具或者作为网络插件的一部分等等。每次你向集群中添加一个新节点时，如果该节点与某 DaemonSet 的规约匹配，则控制面会为该 DaemonSet 调度一个 Pod 到该新节点上运行。
Job 和 CronJob。定义一些一直运行到结束并停止的任务。Job 用来表达的是一次性的任务，而 CronJob 会根据其时间规划反复运行。

cron jobs（工作负载资源的定时任务）

CronJobs 对于创建周期性的、反复重复的任务很有用，例如执行数据备份或者发送邮件。 CronJobs 也可以用来计划在指定时间来执行的独立任务，例如计划当集群看起来很空闲时执行某个 Job。

Daemon Sets（守护进程集，确保副本在集群一组节点运行）

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

DaemonSet 的一些典型用法：

在每个节点上运行集群守护进程
在每个节点上运行日志收集守护进程
在每个节点上运行监控守护进程

一种简单的用法是为每种类型的守护进程在所有的节点上都启动一个 DaemonSet。

Deployments（发布，管理应用副本的api对象）

一个 Deployment 为 Pods 和 ReplicaSets 提供声明式的更新能力。你可以定义 Deployment 以创建新的 ReplicaSet，或删除现有 Deployment，并通过新的 Deployment 收养其资源。

以下是 Deployments 的典型用例：

创建 Deployment 以将 ReplicaSet 上线。 ReplicaSet 在后台创建 Pods。检查 ReplicaSet 的上线状态，查看其是否成功。
通过更新 Deployment 的 PodTemplateSpec，声明 Pod 的新状态。新的 ReplicaSet 会被创建，Deployment 以受控速率将 Pod 从旧 ReplicaSet 迁移到新 ReplicaSet。每个新的 ReplicaSet 都会更新 Deployment 的修订版本。
如果 Deployment 的当前状态不稳定，回滚到较早的 Deployment 版本。每次回滚都会更新 Deployment 的修订版本。
扩大 Deployment 规模以承担更多负载。
暂停 Deployment 以应用对 PodTemplateSpec 所作的多项修改，然后恢复其执行以启动新的上线版本。
使用 Deployment 状态来判定上线过程是否出现停滞。
清理较旧的不再需要的 ReplicaSet 。

Jobs（启动Pods）

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

Pods(最小的可部署的计算单元)

通常你不需要直接创建 Pod，甚至单实例 Pod。相反，你会使用诸如 Deployment 或 Job 这类工作负载资源来创建 Pod。

Kubernetes 集群中的 Pod 主要有两种用法：

运行单个容器的 Pod。**”每个 Pod 一个容器”**模型是最常见的 Kubernetes 用例；在这种情况下，可以将 Pod 看作单个容器的包装器，并且 Kubernetes 直接管理 Pod，而不是容器。
运行多个协同工作的容器的 Pod。 Pod 可能封装由多个紧密耦合且需要共享资源的共处容器组成的应用程序。这些位于同一位置的容器可能形成单个内聚的服务单元 —— 一个容器将文件从共享卷提供给公众，而另一个单独的“边车”（sidecar）容器则刷新或更新这些文件。 Pod 将这些容器和存储资源打包为一个可管理的实体。

每个 Pod 都旨在运行给定应用程序的单个实例。如果希望横向扩展应用程序（例如，运行多个实例以提供更多的资源），则应该使用多个 Pod，每个实例使用一个 Pod。在 Kubernetes 中，这通常被称为 副本（Replication）。通常使用一种工作负载资源及其控制器来创建和管理一组 Pod 副本。

你可以使用工作负载资源来创建和管理多个 Pod。资源的控制器能够处理副本的管理、上线，并在 Pod 失效时提供自愈能力。例如，如果一个节点失败，控制器注意到该节点上的 Pod 已经停止工作，就可以创建替换性的 Pod。调度器会将替身 Pod 调度到一个健康的节点执行。

下面是一些管理一个或者多个 Pod 的工作负载资源的示例：

ReplicaSet(Pod 副本的稳定集合，鸡肋)

何时使用 ReplicaSet:

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

这实际上意味着，你可能永远不需要操作 ReplicaSet 对象：而是使用 Deployment，并在 spec 部分定义你的应用。

ReplicationController（确保一个 Pod 或一组同类的 Pod 总是可用的，鸡肋）

当 Pod 数量过多时，ReplicationController 会终止多余的 Pod。当 Pod 数量太少时，ReplicationController 将会启动新的 Pod。与手动创建的 Pod 不同，由 ReplicationController 创建的 Pod 在失败、被删除或被终止时会被自动替换。

ReplicationController 的替代方案

ReplicaSet

ReplicaSet 是下一代 ReplicationController，支持新的基于集合的标签选择算符。它主要被 Deployment 用来作为一种编排 Pod 创建、删除及更新的机制。请注意，我们推荐使用 Deployment 而不是直接使用 ReplicaSet，除非你需要自定义更新编排或根本不需要更新。

Deployment （推荐）

Deployment 是一种更高级别的 API 对象，它以类似于 kubectl rolling-update 的方式更新其底层 ReplicaSet 及其 Pod。如果你想要这种滚动更新功能，那么推荐使用 Deployment，因为与 kubectl rolling-update 不同，它们是声明式的、服务端的，并且具有其它特性。

裸 Pod

与用户直接创建 Pod 的情况不同，ReplicationController 能够替换因某些原因被删除或被终止的 Pod ，例如在节点故障或中断节点维护的情况下，例如内核升级。因此，我们建议你使用 ReplicationController，即使你的应用程序只需要一个 Pod。可以将其看作类似于进程管理器，它只管理跨多个节点的多个 Pod ，而不是单个节点上的单个进程。 ReplicationController 将本地容器重启委托给节点上的某个代理(例如，Kubelet 或 Docker)。

Job

对于预期会自行终止的 Pod (即批处理任务)，使用 Job 而不是 ReplicationController。

DaemonSet

对于提供机器级功能（例如机器监控或机器日志记录）的 Pod，使用 DaemonSet 而不是 ReplicationController。这些 Pod 的生命期与机器的生命期绑定：它们需要在其他 Pod 启动之前在机器上运行，并且在机器准备重新启动或者关闭时安全地终止。

StatefulSets（管理某 Pod 集合的部署和扩缩，并为这些 Pod 提供持久存储和持久标识符，也很少用）

使用 StatefulSets

StatefulSets 对于需要满足以下一个或多个需求的应用程序很有价值：

稳定的、唯一的网络标识符。
稳定的、持久的存储。
有序的、优雅的部署和缩放。
有序的、自动的滚动更新。

在上面描述中，“稳定的”意味着 Pod 调度或重调度的整个过程是有持久性的。如果应用程序不需要任何稳定的标识符或有序的部署、删除或伸缩，则应该使用由一组无状态的副本控制器提供的工作负载来部署应用程序，比如 Deployment 或者 ReplicaSet 可能更适用于你的无状态应用部署需要。

限制

给定 Pod 的存储必须由 PersistentVolume 驱动基于所请求的 storage class 来提供，或者由管理员预先提供。
删除或者收缩 StatefulSet 并不会删除它关联的存储卷。这样做是为了保证数据安全，它通常比自动清除 StatefulSet 所有相关的资源更有价值。
StatefulSet 当前需要无头服务来负责 Pod 的网络标识。你需要负责创建此服务。
当删除 StatefulSets 时，StatefulSet 不提供任何终止 Pod 的保证。为了实现 StatefulSet 中的 Pod 可以有序地且体面地终止，可以在删除之前将 StatefulSet 缩放为 0。
在默认 Pod 管理策略(OrderedReady) 时使用滚动更新，可能进入需要人工干预才能修复的损坏状态。

Discovery and Load Balancing

Ingresses(提供负载均衡、SSL 终结和基于名称的虚拟托管)

Ingress 公开了从集群外部到集群内服务的 HTTP 和 HTTPS 路由。流量路由由 Ingress 资源上定义的规则控制。

下面是一个将所有流量都发送到同一 Service 的简单 Ingress 示例：

一个最小的 Ingress 资源示例：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: minimal-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - http:
      paths:
      - path: /testpath
        pathType: Prefix
        backend:
          service:
            name: test
            port:
              number: 80

Ingress 控制器

为了让 Ingress 资源工作，集群必须有一个正在运行的 Ingress 控制器。

与作为 kube-controller-manager 可执行文件的一部分运行的其他类型的控制器不同， Ingress 控制器不是随集群自动启动的。基于此页面，你可选择最适合你的集群的 ingress 控制器实现。

Kubernetes 作为一个项目，目前支持和维护 AWS， GCE 和 nginx Ingress 控制器。

其他控制器：https://kubernetes.io/zh/docs/concepts/services-networking/ingress-controllers/#%E5%85%B6%E4%BB%96%E6%8E%A7%E5%88%B6%E5%99%A8

Services(将运行在一组 Pods 上的应用程序公开为网络服务的抽象方法)

你无需修改应用程序即可使用不熟悉的服务发现机制。 Kubernetes 为 Pods 提供自己的 IP 地址，并为一组 Pod 提供相同的 DNS 名，并且可以在它们之间进行负载均衡。

举个例子，考虑一个图片处理后端，它运行了 3 个副本。这些副本是可互换的 —— 前端不需要关心它们调用了哪个后端副本。然而组成这一组后端程序的 Pod 实际上可能会发生变化，前端客户端不应该也没必要知道，而且也不需要跟踪这一组后端的状态。

Service 定义的抽象能够解耦这种关联。

例如，假定有一组 Pod，它们对外暴露了 9376 端口，同时还被打上 app=MyApp 标签：

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: MyApp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

上述配置创建一个名称为 “my-service” 的 Service 对象，它会将请求代理到使用 TCP 端口 9376，并且具有标签 "app=MyApp" 的 Pod 上。

Kubernetes 为该服务分配一个 IP 地址（有时称为 “集群IP”），该 IP 地址由服务代理使用。 (请参见下面的 VIP 和 Service 代理).

虚拟Ip和service代理

在 Kubernetes 集群中，每个 Node 运行一个 kube-proxy 进程。 kube-proxy 负责为 Service 实现了一种 VIP（虚拟 IP）的形式，而不是 ExternalName 的形式。

1.用户空间模式

2.iptables 代理模式

这种模式，kube-proxy 会监视 Kubernetes 控制节点对 Service 对象和 Endpoints 对象的添加和移除。对每个 Service，它会配置 iptables 规则，从而捕获到达该 Service 的 clusterIP 和端口的请求，进而将请求重定向到 Service 的一组后端中的某个 Pod 上面。对于每个 Endpoints 对象，它也会配置 iptables 规则，这个规则会选择一个后端组合。

默认的策略是，kube-proxy 在 iptables 模式下随机选择一个后端。

使用 iptables 处理流量具有较低的系统开销，因为流量由 Linux netfilter 处理，而无需在用户空间和内核空间之间切换。这种方法也可能更可靠。

如果 kube-proxy 在 iptables 模式下运行，并且所选的第一个 Pod 没有响应，则连接失败。这与用户空间模式不同：在这种情况下，kube-proxy 将检测到与第一个 Pod 的连接已失败，并会自动使用其他后端 Pod 重试。

3.ipvs代理模式

IPVS代理模式基于类似于 iptables 模式的 netfilter 挂钩函数，但是使用哈希表作为基础数据结构，并且在内核空间中工作。这意味着，与 iptables 模式下的 kube-proxy 相比，IPVS 模式下的 kube-proxy 重定向通信的延迟要短，并且在同步代理规则时具有更好的性能。与其他代理模式相比，IPVS 模式还支持更高的网络流量吞吐量。

IPVS 提供了更多选项来平衡后端 Pod 的流量。这些是：

rr：轮替（Round-Robin）
lc：最少链接（Least Connection），即打开链接数量最少者优先
dh：目标地址哈希（Destination Hashing）
sh：源地址哈希（Source Hashing）
sed：最短预期延迟（Shortest Expected Delay）
nq：从不排队（Never Queue）

Config and Storage

Config Maps(用来将非机密性的数据保存到键值对中)

ConfigMap 将您的环境配置信息和容器镜像解耦，便于应用配置的修改。

在 ConfigMap 中保存的数据不可超过 1 MiB。如果你需要保存超出此尺寸限制的数据，你可能希望考虑挂载存储卷或者使用独立的数据库或者文件服务。

ConfigMap 使用 data 和 binaryData 字段。这些字段能够接收键-值对作为其取值。data 和 binaryData 字段都是可选的。data 字段设计用来保存 UTF-8 字节序列，而 binaryData 则被设计用来保存二进制数据作为 base64 编码的字串。

persistent volume claims(Pod 使用 PersistentVolumeClaim 来请求物理存储)

创建 PersistentVolumeClaim 之后，Kubernetes 控制平面将查找满足申领要求的 PersistentVolume。如果控制平面找到具有相同 StorageClass 的适当的 PersistentVolume，则将 PersistentVolumeClaim 绑定到该 PersistentVolume 上。

Secrets

Secret 对象类型用来保存敏感信息，例如密码、OAuth 令牌和 SSH 密钥。将这些信息放在 secret 中比放在 Pod 的定义或者容器镜像中来说更加安全和灵活。在创建 Secret 对象时，你可以使用 Secret 资源的 type 字段，或者与其等价的 kubectl 命令行参数（如果有的话）为其设置类型。 Secret 的类型用来帮助编写程序处理 Secret 数据。

Kubernetes 提供若干种内置的类型，用于一些常见的使用场景。针对这些类型，Kubernetes 所执行的合法性检查操作以及对其所实施的限制各不相同。

内置类型	用法
`Opaque`	用户定义的任意数据
`kubernetes.io/service-account-token`	服务账号令牌
`kubernetes.io/dockercfg`	`~/.dockercfg` 文件的序列化形式
`kubernetes.io/dockerconfigjson`	`~/.docker/config.json` 文件的序列化形式
`kubernetes.io/basic-auth`	用于基本身份认证的凭据
`kubernetes.io/ssh-auth`	用于 SSH 身份认证的凭据
`kubernetes.io/tls`	用于 TLS 客户端或者服务器端的数据
`bootstrap.kubernetes.io/token`	启动引导令牌数据