Kubernetes笔记

写这篇文章是为了收集来自不同来源的笔记。

“Kubernetes 是一个可移植、可扩展的开源平台，用于管理容器化工作负载和服务，有助于声明式配置和自动化。它拥有庞大且快速发展的生态系统。Kubernetes 服务、支持和工具随处可见。[0]”

您至少需要了解以下术语。

Pods

Kubernetes 中可以部署的最小单元。

实际上，Pod 是一个或多个容器，它们协同工作以服务于系统的一部分。

每个 Pod 都有一个唯一的 IP 地址。

Pod 中的容器可以通过 localhost 相互通信。

但大多数情况下，每个 pod 都包含一个容器。

**“注意：**在单个 Pod 中对多个位于同一位置并共同管理的容器进行分组是一个相对高级的用例。您应该仅在容器紧密耦合的特定实例中使用此模式”[3]。

Replica Set

“ReplicaSet 的目的是在任何给定时间保持一组稳定的副本 Pod 运行。因此，它通常用于保证指定数量的相同 Pod 的可用性。”

引入状态管理

Deployments

副本集之上的抽象级别

部署创建和更新副本集

ConfigMaps

用于覆盖特定于容器的数据，如

• 配置文件
• 环境变量
• 整个数据目录

“应用程序有时将配置存储为代码中的常量。这违反了十二要素，它要求严格分离配置和代码。配置在不同的部署中差别很大，而代码不会。”[5] 这就是为什么使用 ConfigMap 来处理这种情况。

更改时在容器内自动更新

最佳实践是版本 ConfigMaps 并执行滚动更新

“ConfigMaps 可以作为数据卷挂载。ConfigMaps 也可以被系统的其他部分使用，而无需直接暴露给 Pod。例如，ConfigMaps 可以保存系统其他部分应该用于配置的数据。”[4]

Using ConfigMaps as files from a Pod

使用 ConfigMaps 作为来自 Pod 的文件

要在 Pod 的卷中使用 ConfigMap：

• 创建一个 ConfigMap 或使用现有的。多个 Pod 可以引用同一个 ConfigMap。

• 修改您的 Pod 定义以在.spec.volumes[]. 将卷命名为任何名称，并.spec.volumes[].configMap.name设置一个字段以引用您的 ConfigMap 对象。

• .spec.containers[].volumeMounts[]向需要 ConfigMap 的每个容器添加一个。将.spec.containers[].volumeMounts[].readOnly = true和指定.spec.containers[].volumeMounts[].mountPath为您希望 ConfigMap 出现的未使用目录名称。

• 修改您的图像或命令行，以便程序在该目录中查找文件。ConfigMapdata映射中的每个键都成为mountPath.

这是在卷中安装 ConfigMap 的 Pod 示例：

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mypod
    image: redis
    volumeMounts:
    - name: foo
      mountPath: "/etc/foo"
      readOnly: true
  volumes:
  - name: foo
    configMap:
      name: myconfigmap

“当当前在卷中使用的 ConfigMap 更新时，预计的键最终也会更新。kubelet 在每次定期同步时检查挂载的 ConfigMap 是否是最新的。但是，kubelet 使用其本地缓存来获取 ConfigMap 的当前值。缓存的类型可以使用KubeletConfiguration 结构中的ConfigMapAndSecretChangeDetectionStrategy字段进行配置. ConfigMap 可以通过 watch（默认）、基于 ttl 或通过将所有请求直接重定向到 API 服务器来传播。因此，从更新 ConfigMap 到将新键投射到 Pod 的总延迟可以与 kubelet 同步周期 + 缓存传播延迟一样长，其中缓存传播延迟取决于选择的缓存类型（它等于观察传播延迟、缓存的 ttl 或相应的零）。”[4]

Services

“定义一个 DNS 条目，可用于引用一组 pod

为 Pod 组提供一致的端点

不同类型的 ClusterIP、NodePort、LoadBalancer

• ClusterIP：在集群内部 IP 上公开服务。选择此值会使服务只能从集群内部访问。这是默认值ServiceType。
• NodePort：在每个节点的 IP 上的静态端口 ( NodePort)上公开服务。甲ClusterIP服务，向其中的NodePort服务的路由，自动创建。您将能够NodePort通过请求从集群外部联系服务<NodeIP>:<NodePort>。
• LoadBalancer：使用云提供商的负载均衡器在外部公开服务。NodePort和ClusterIP服务，外部负载平衡器路由到的，是自动创建的。”

Ingresses

定义集群外部的流量如何路由到集群内部；用于向全世界公开 Kubernetes 服务；根据主机和路径等因素将流量路由到内部服务Ingress 通常由负载均衡器（Nginx、HAProxy 等）实现，就像第 7 层负载均衡器。

Ingress 的开发是为了降低云中的负载均衡器成本。如果我们为每个服务使用一个负载均衡器（Services type -> LoadBalancer），成本非常高。这就是我们使用入口的原因。

我将针对不同的主题合并这样的资源。回购：

0-) https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/

1-) https://www.youtube.com/watch?v=5h1TCrh_hZ0

2-) https://www.cncf.io/blog/2019/12/16/kubernetes-101/

3-) https://kubernetes.io/docs/concepts/workloads/pods/

4-) https://kubernetes.io/docs/concepts/configuration/configmap/

5-) https://12factor.net/config