service-deployment.yaml 示例

apiVersion: apps/v1
kind: Deployment
metadata:name: example-plusnamespace: aaaalabels:app: example-prdapp_unit: AAAA-EXAMPLE
spec:replicas: 2selector:matchLabels:app: example-prdtemplate:metadata:labels:app: example-prdapp_unit: AAAA-EXAMPLEspec:restartPolicy: AlwaysimagePullSecrets:- name: registrykeynodeSelector:app_name: shareaffinity:podAntiAffinity:preferredDuringSchedulingIgnoredDuringExecution:- weight: 100podAffinityTerm:labelSelector:matchExpressions:- key: appoperator: Invalues:- example-prdtopologyKey: kubernetes.io/hostnamecontainers:- name: example-prdimage: artifactory.com.cn/image/example:20241111imagePullPolicy: IfNotPresentports:- name: httpcontainerPort: 22protocol: TCPresources:requests:memory: "8Gi"cpu: "4"limits:memory: "12Gi"cpu: "6"lifecycle:preStop:exec:command: ["/bin/bash", "-c", "cat /etc/profile"]livenessProbe:tcpSocket:port: 22initialDelaySeconds: 60timeoutSeconds: 30periodSeconds: 15successThreshold: 1failureThreshold: 3readinessProbe:tcpSocket:port: 22initialDelaySeconds: 20timeoutSeconds: 30periodSeconds: 5successThreshold: 1failureThreshold: 3env:- name: MONITOR_TYPEvalue: "CONTAINER_ONLY"- name: test_logs-examplevalue: stdout- name: test_logs-example_tagsvalue: topic=elk-k8s-aaaa- name: MODULEvalue: "test"volumeMounts:- name: online-configmountPath: /run/secrets/global.confsubPath: global.conf- name: jiemi-configmountPath: /home/jdk/001.acpksubPath: 001.acpk- name: jiemi-configmountPath: /home/jdk/bris_secret_app_20200116.jarsubPath: bris_secret_app_20200116.jarvolumes:- name: online-configconfigMap:name: configitems:- key: "global.conf"path: "global.conf"- name: jiemi-configconfigMap:name: jiemiitems:- key: "1111.acpk"path: "001.acpk"- key: "bris_secret_app_20200116.jar"path: "bris_secret_app_20200116.jar"---
apiVersion: v1
kind: Service
metadata:name: example-service-plusnamespace: aaaalabels:app_unit: AAAA-EXAMPLE
spec:selector:app: example-prdports:- name: example-prdport: 22targetPort: 22

逐行解释

逐行解释每一部分的作用和含义：

apiVersion: apps/v1

• apiVersion: 指定要使用的 Kubernetes API 版本。
• apps/v1: 使用的是 Apps API 中的 v1 版本，表示该文件定义了 Deployment 类型的资源。

kind: Deployment

• kind: 指定要创建的 Kubernetes 资源类型。
• Deployment: 表示定义了一个部署资源。

metadata:name: example-plusnamespace: aaaalabels:app: example-prdapp_unit: AAAA-EXAMPLE

• metadata: 定义资源的元数据信息。
  • name: 指定资源的名称为 example-plus。
  • namespace: 指定资源所属的命名空间为 aaaa。
  • labels: 为资源添加标签，用于标识和选择资源。

spec:replicas: 2selector:matchLabels:app: example-prdtemplate:metadata:labels:app: example-prdapp_unit: AAAA-EXAMPLE

• spec: 定义了资源的规格（specification）部分，即资源的具体配置信息。
  • replicas: 2: 指定要创建的 Pod 实例数量为 2 个。
  • selector: 定义了用于选择 Pod 的标签。
    • matchLabels: 指定要匹配的标签，这里选择带有 app: example-prd 的 Pod。
  • template: 定义了要创建的 Pod 的模板。
    • metadata.labels: 为创建的 Pod 添加标签，与 Deployment 的标签保持一致。

接下来是 Pod 模板的详细配置，包括容器、资源请求、生命周期管理等，我将分段解释：

spec:restartPolicy: Always

• restartPolicy: Always: 定义容器的重启策略为始终重启。

  imagePullSecrets:- name: registrykey

• imagePullSecrets: 定义了从私有镜像仓库拉取镜像所需的密钥或凭证，这里使用了名为 registrykey 的密钥。

  nodeSelector:app_name: share

• nodeSelector: 根据节点的标签选择在哪些节点上调度 Pod，这里选择带有 app_name: share 的节点。

  affinity:podAntiAffinity:preferredDuringSchedulingIgnoredDuringExecution:- weight: 100podAffinityTerm:labelSelector:matchExpressions:- key: appoperator: Invalues:- example-prdtopologyKey: kubernetes.io/hostname

• affinity: 定义 Pod 的亲和性，控制 Pod 如何在集群中分布。
  • podAntiAffinity: 定义 Pod 的反亲和性，即 Pod 倾向于不被调度到与特定标签相同的其他 Pod 所在的节点上。
    • preferredDuringSchedulingIgnoredDuringExecution: 设置优先级，表示在调度时优先避免与相同标签的其他 Pod 调度在一起。
      • weight: 100: 设置优先级权重为 100。
      • labelSelector: 指定要匹配的标签选择器，这里选择带有 app: example-prd 的 Pod。
        • topologyKey: kubernetes.io/hostname: 指定拓扑域的键，这里使用节点的主机名作为拓扑域的键。

接下来是容器的配置：

containers:- name: example-prdimage: artifactory.com.cn/image/example:20241111imagePullPolicy: IfNotPresent

• containers: 定义了要运行的容器列表。
  • name: 容器的名称为 example-prd。
  • image: 指定容器要使用的镜像地址。
  • imagePullPolicy: IfNotPresent: 设置容器拉取镜像的策略为如果本地不存在该镜像才拉取。

继续容器的配置：

    ports:- name: httpcontainerPort: 22protocol: TCP

• ports: 定义容器暴露的端口列表。
  • name: http: 定义端口的名称为 http。
  • containerPort: 22: 容器内部的端口号为 22。
  • protocol: TCP: 指定端口的协议为 TCP。

接着是容器的资源请求和限制：

    resources:requests:memory: "8Gi"cpu: "4"limits:memory: "12Gi"cpu: "6"

• resources: 定义容器的资源请求和限制。
  • requests: 指定容器所需的最低资源量，包括内存和CPU。
  • limits: 指定容器的资源上限，包括内存和CPU。

继续是容器的生命周期管理和健康检查：

    lifecycle:preStop:exec:command: ["/bin/bash", "-c", "cat /etc/profile"]livenessProbe:tcpSocket:port: 22initialDelaySeconds: 60timeoutSeconds: 30periodSeconds: 15successThreshold: 1failureThreshold: 3readinessProbe:tcpSocket:port: 22initialDelaySeconds: 20timeoutSeconds: 30periodSeconds: 5successThreshold: 1failureThreshold: 3

• lifecycle: 定义容器的生命周期管理，这里在容器停止之前执行一个命令。
  • preStop: 容器停止之前执行的操作。
    • exec: 使用 exec 执行一个命令。

上面的配置表示，在容器即将停止之前（例如在容器被 Kubernetes 关闭之前），会执行指定的命令 /bin/bash -c "cat /etc/profile"。具体来说：

• /bin/bash -c "cat /etc/profile"：这个命令会在容器中执行，它的作用是打印输出 /etc/profile 文件的内容。
• 这个操作可以用来在容器即将停止之前执行一些清理或日志记录操作，以确保容器停止前的一些状态或信息被记录下来。

这样的设置对于一些特定的容器应用可能很有用，例如在容器关闭之前需要执行一些清理操作或者记录重要日志信息。这样做可以确保容器关闭时的状态或信息得以保存或记录。

• livenessProbe：定义容器的存活性检测，用于判断容器是否处于健康状态。
  • tcpSocket：使用 TCP Socket 进行存活性检测。
  • port: 22：指定检测的端口号为 22。
  • initialDelaySeconds: 60：容器启动后等待 60 秒后开始进行首次存活性检测。
  • timeoutSeconds: 30：每次检测的超时时间为 30 秒。
  • periodSeconds: 15：每隔 15 秒进行一次存活性检测。
  • successThreshold: 1：连续成功检测 1 次后认定容器为存活。
  • failureThreshold: 3：连续失败检测 3 次后认定容器为不存活。
• readinessProbe：定义容器的就绪性检测，用于判断容器是否准备好接收流量。
  • tcpSocket：使用 TCP Socket 进行就绪性检测。
  • port: 22：指定检测的端口号为 22。
  • initialDelaySeconds: 20：容器启动后等待 20 秒后开始进行首次就绪性检测。
  • timeoutSeconds: 30：每次检测的超时时间为 30 秒。
  • periodSeconds: 5：每隔 5 秒进行一次就绪性检测。
  • successThreshold: 1：连续成功检测 1 次后认定容器为就绪状态。
  • failureThreshold: 3：连续失败检测 3 次后认定容器为不就绪状态。

这些配置用于指定 Kubernetes 如何检测和管理容器的存活性和就绪性。存活性检测用于保证容器在运行过程中不会因为某些问题而停止运行，而就绪性检测则用于确保容器能够接收流量进行服务。这些参数需要根据具体的应用特性和需求来进行调整和配置。

环境变量 (env):

env:- name: MONITOR_TYPEvalue: "CONTAINER_ONLY"- name: test_logs-examplevalue: stdout- name: test_logs-example_tagsvalue: topic=elk-k8s-aaaa- name: MODULEvalue: "test"

这部分配置定义了容器中的环境变量，每个条目包含了一个环境变量的名称 (name) 和对应的值 (value)。
例如，MONITOR_TYPE 的值是 “CONTAINER_ONLY”，等等。

Volume 挂载 (volumeMounts):

volumeMounts:- name: online-configmountPath: /run/secrets/global.confsubPath: global.conf- name: jiemi-configmountPath: /home/jdk/001.acpksubPath: 001.acpk- name: jiemi-configmountPath: /home/jdk/bris_secret_app_20200116.jarsubPath: bris_secret_app_20200116.jar

• 这部分配置定义了容器内文件系统的挂载点，将持久化卷（volumes）挂载到容器中，使容器可以访问这些文件。
• 每个条目指定了挂载的名称 (name)、挂载的路径 (mountPath) 和子路径 (subPath)。

Volumes 定义 (volumes):

volumes:- name: online-configconfigMap:name: configitems:- key: "global.conf"path: "global.conf"- name: jiemi-configconfigMap:name: jiemiitems:- key: "1111.acpk"path: "001.acpk"- key: "bris_secret_app_20200116.jar"path: "bris_secret_app_20200116.jar"

• 这部分配置定义了容器使用的持久化卷（volumes）。
• 每个条目指定了卷的名称 (name)，并且指定了从 ConfigMap 中获取数据的方式 (configMap)，包括 ConfigMap 的名称 (name) 和其中的条目 (items)，每个条目指定了键 (key) 和对应的路径 (path)。

这些配置共同定义了容器的环境变量、文件系统挂载点和持久化卷，使得容器能够以正确的配置和资源访问运行所需的信息和数据。

Service 对象：

---
apiVersion: v1
kind: Service
metadata:name: example-service-plusnamespace: aaaalabels:app_unit: AAAA-EXAMPLE

• apiVersion: v1: 表示使用的 Kubernetes API 版本是 v1。
• kind: Service: 定义了一个 Kubernetes Service 对象，用于暴露应用程序到集群内部或外部的访问。
• metadata: 元数据部分，用于定义对象的基本信息。
  • name: example-service-plus: Service 的名称为 example-service-plus。
  • namespace: aaaa: Service 所属的命名空间为 aaaa。
  • labels: 定义了标签，其中 app_unit: AAAA-EXAMPLE 表示这个 Service 关联到标签为 app_unit: AAAA-EXAMPLE 的资源。

spec:selector:app: example-prdports:- name: example-prdport: 22targetPort: 22

• spec: 定义了 Service 的规格，包括选择器和端口信息。
  • selector: 指定了由该 Service 管理的 Pod 的标签选择器。这里的 app: example-prd 表示选择标签为 app: example-prd 的 Pod。
  • ports: 指定了 Service 所暴露的端口信息。
    • name: example-prd: 端口的名称为 example-prd，可用于区分多个端口。
    • port: 22: Service 所监听的端口号为 22，表示外部对该 Service 的访问将使用该端口号。
    • targetPort: 22: 将进入该 Service 的流量转发到 Pod 的端口号为 22 的容器。

ports 部分的 name 字段是可选的，您可以不提供该字段。如果不指定 name 字段，则 Kubernetes 会自动为该端口生成一个默认的名称。通常是一个格式化的字符串，类似于 <protocol>-<port>-<auto-generated-number>。在实际使用中，如果不需要对端口进行特别的命名或区分，只是简单地暴露端口用于服务访问，可以不提供 name 字段，让 Kubernetes 自动生成默认的名称即可。但如果需要更好地理解和管理端口配置，建议还是为端口提供一个描述性的名称。

总体来说，这份配置定义了一个名为 example-service-plus 的 Service 对象，它位于命名空间 aaaa 中，并且通过标签选择器 app: example-prd 与具有相同标签的 Pod 相关联，监听端口号为 22，转发流量到 Pod 内部的 22 端口。这样就可以通过 Service 的名称和端口号来访问与该 Service 关联的 Pod。

问题：

问题1

metadata.labels: 为创建的 Pod 添加标签，与 Deployment 的标签保持一致。为什么要保持一致呢？

保持标签一致性在 Kubernetes 中是一种良好的实践，它有助于组织和管理您的资源，使您的部署更加可靠和可维护。以下是保持标签一致性的一些重要原因：

• 标识和选择：
  • 标识性: 标签用于标识资源，例如应用程序名称、环境（开发、测试、生产）等。
  • 选择性:使用标签选择器（selector）时，确保标签一致性可以确保正确地选择相关资源。在这种情况下，Deployment 和 Pod 使用相同的标签，确保 Pod 是由该 Deployment 管理的。
• 自动化管理：
  • 一致的标签使得自动化管理更加简单。例如，您可以编写自动化脚本或配置管理工具来根据标签选择和操作资源，保持标签一致性可以减少错误和混淆。
• 监控和日志：
  • 一致的标签可以帮助您在监控系统或日志记录中识别和过滤特定的资源。例如，您可以轻松地使用标签筛选出特定应用程序或环境的日志或监控数据。
• 安全性：
  • 使用一致的标签还可以帮助您管理访问控制和安全策略。您可以基于标签定义安全策略，确保只有符合特定标签要求的资源可以访问特定服务或资源。
• 维护和扩展：
  • 当您需要维护或扩展部署时，一致的标签可以确保您可以准确地识别和操作相关的资源，而不会误操作或造成不必要的影响。

因此，保持标签一致性有助于提高资源管理的效率、可靠性和安全性，是 Kubernetes 中推荐的最佳实践之一。

问题2

• restartPolicy: Always: 定义容器的重启策略为始终重启。什么意思？

restartPolicy: Always 是针对 Kubernetes 中容器的重启策略。解释一下这个设置的含义和作用：

在 Kubernetes 中，每个容器都有一个与之相关联的重启策略。restartPolicy 字段用于定义容器的重启行为，其中包括三种主要的选项：Always、OnFailure 和 Never。

• Always: 当容器退出（无论是正常退出还是异常退出）时，Kubernetes 会始终重启该容器。这意味着无论何时容器停止运行，Kubernetes 都会尝试将其重新启动到期望的状态。
• OnFailure: 只有当容器以非零状态退出（即出现失败）时，Kubernetes 才会重启该容器。如果容器以零状态（即成功）退出，则不会自动重启。
• Never: Kubernetes 不会自动重启容器，即使容器退出或失败。

在您的配置中，将 restartPolicy 设置为 Always，意味着您希望 Kubernetes 始终保持容器的运行状态，并在容器停止时立即重启它们。这对于需要持续运行的应用程序或服务非常有用，以确保它们在出现问题时可以快速恢复并继续提供服务。

问题3

• imagePullSecrets: 定义了从私有镜像仓库拉取镜像所需的密钥或凭证，这里使用了名为 registrykey 的密钥。怎么获取呢？

要获取 Kubernetes 中用于拉取私有镜像的凭证（密钥），您需要首先创建一个 Secret 对象，并将其指定为 imagePullSecrets 字段的值。这个 Secret 对象包含了您私有镜像仓库的认证信息。

以下是一般步骤：
1、创建 Secret 对象：

kubectl create secret docker-registry <secret-name> \--docker-server=<registry-server> \--docker-username=<username> \--docker-password=<password> \--docker-email=<email>

<secret-name>: 指定 Secret 对象的名称。
<registry-server>: 私有镜像仓库的地址。
<username>: 认证用户名。
<password>: 认证密码。
<email>: 关联的邮箱地址（可选）。

2、将 Secret 配置到 Deployment 中：
在您的 Deployment YAML 文件中，将创建的 Secret 名称配置到 imagePullSecrets 字段下：

imagePullSecrets:- name: <secret-name>

3、应用更新：
使用 kubectl apply -f your-deployment.yaml 命令或类似命令将更新的 Deployment 配置应用到 Kubernetes 集群中。
这样，Kubernetes 将能够使用指定的凭证从私有镜像仓库拉取镜像。
请确保 <secret-name>、<registry-server>、<username>、<password> 和 <email> 的值与您的实际情况相匹配。同时，要保护好敏感信息（如密码），避免明文存储或传输。

问题4

• nodeSelector: 根据节点的标签选择在哪些节点上调度 Pod，这里选择带有 app_name: share 的节点。解释一下

nodeSelector 是 Kubernetes 中用于节点调度的一种方式，可以根据节点的标签选择在哪些节点上调度 Pod。让我们详细解释一下这段配置的含义和作用：

在 Kubernetes 中，集群中的每个节点都可以通过标签进行标识，这些标签可以根据您的需求进行定义和设置。通过 nodeSelector 字段，您可以告诉 Kubernetes 在调度 Pod 时只选择带有特定标签的节点。

• nodeSelector：这个字段用于指定节点调度的规则，即选择在哪些节点上调度 Pod。
• app_name: share：这是一个标签选择器，表示希望将 Pod 调度到带有 app_name: share 标签的节点上。

这样配置的目的可能是为了将特定类型的工作负载调度到具有特定功能或资源的节点上。例如，在这里可能有一些被标记为 app_name: share 的节点，它们可能配置了特定的硬件、网络或存储资源，或者可能专门用于运行特定类型的应用程序。通过这样的标签选择器，可以确保 Pod 被调度到适合它们需求的节点上。

问题5

matchExpressions: - key: app operator: In values: - example-prd，啥意思

这段配置中的 matchExpressions 是 Kubernetes 中用于选择器匹配的一部分。让我们来详细解释一下这个配置的含义：

在 Kubernetes 中，标签选择器（Label Selectors）用于选择要与之关联的资源，如 Pod、Service 等。matchExpressions 是用于更复杂的标签匹配条件的一部分，允许您指定多个条件以匹配标签。

matchExpressions:- key: appoperator: Invalues:- example-prd

• matchExpressions：这是一个用于选择器匹配的表达式列表。
  • - key: app：指定要匹配的标签键为 app。
  • operator: In：指定匹配操作符为 In，表示标签的值必须包含在指定的值列表中才能匹配。
  • values：指定要匹配的值列表，这里只有一个值 example-prd。

这段配置的意思是，要选择带有 app: example-prd 标签的资源（例如 Pod），因为这个条件是 In，所以只有标签的值为 example-prd 的资源才会被选择。这样可以确保只有特定类型或特定用途的资源会被选择器匹配。

问题6

• topologyKey: kubernetes.io/hostname: 指定拓扑域的键，这里使用节点的主机名作为拓扑域的键。解释一下

在 Kubernetes 中，topologyKey 是用于定义拓扑域键的字段，它影响 Pod 的调度行为和容错能力。让我们详细解释一下这个配置的含义：

1、拓扑域（Topology Domain）：

• Kubernetes 集群中的拓扑域是指一组相关联的节点，它们可能位于同一区域、同一机架或具有相似的硬件特性。

2、topologyKey 字段：

• topologyKey 字段用于指定拓扑域的键，即确定拓扑域的方式。
• 在这里配置为 kubernetes.io/hostname，表示使用节点的主机名作为拓扑域的键。

3、作用：

• 当 Pod 的调度需要考虑拓扑域时（如使用 PodAntiAffinity 配置避免在同一拓扑域内调度多个相关 Pod），Kubernetes 使用指定的拓扑域键来判断节点的拓扑位置。
• 使用节点的主机名作为拓扑域键意味着 Kubernetes 将根据节点的主机名来确定节点所属的拓扑域。如果节点的主机名相同或符合某种规律，它们就会被认为属于同一拓扑域。

4、适用情况：

• 在多节点的 Kubernetes 集群中，如果您有多个拓扑域（例如不同的机架、不同的区域），可以使用 topologyKey 来确保相关的 Pod 在不同的拓扑域内调度，从而提高容错性和可用性。

总之，通过配置 topologyKey: kubernetes.io/hostname，您告诉 Kubernetes 在进行 Pod 调度时使用节点的主机名作为拓扑域的键，这样可以根据节点的拓扑位置来确保 Pod 的合适调度。

问题7

为什么一个是apiVersion: apps/v1，一个是apiVersion: v1
在 Kubernetes 中，不同的资源对象有不同的 API 版本。这也反映了 Kubernetes 的发展和不同资源类型之间的区别。

1. apiVersion: apps/v1：这个版本用于定义 Deployment、StatefulSet、DaemonSet 等应用相关的控制器对象。通常情况下，用于部署应用的控制器对象会使用 apps/v1 版本，因为这些控制器对象属于应用级别的管理。
2. apiVersion: v1：这个版本用于定义 Kubernetes 中的核心资源对象，例如 Pod、Service、Namespace 等。这些对象是 Kubernetes 集群的基本构建块，因此使用的是核心的 API 版本。

因此，在您提供的配置中，Deployment 对象使用的是 apiVersion: apps/v1，因为 Deployment 是用于部署和管理应用的控制器对象。而 Service 对象使用的是 apiVersion: v1，因为 Service 是 Kubernetes 的核心资源之一，用于暴露应用到集群内部或外部的访问。

总体来说，不同类型的资源对象对应不同的 API 版本，这是 Kubernetes 中区分不同资源类型的重要标识之一。

结构图片