组件

Kubernetes (K8s) 是一个用于自动化容器化应用程序部署、扩展和管理的开源平台。它由多个组件组成，这些组件彼此协作，以实现集群的管理和调度。以下是 Kubernetes 的主要组件及其关系的概述：

1. 控制平面 (Control Plane)

控制平面是 Kubernetes 的核心，负责管理和调度集群的状态。

• API Server：

  • 提供 Kubernetes API，所有组件通过它进行通信。
  • 负责处理 REST 操作，并更新 etcd 存储。

• etcd：

  • 一个高可用的键值存储，用于保存集群的所有配置数据和状态信息。
  • 所有集群状态信息都保存在这里，包括节点状态、Pod 状态等。

• Scheduler：

  • 负责将未分配的 Pods 调度到合适的节点上。
  • 根据资源需求、负载等策略选择节点。

• Controller Manager：

  • 管理控制循环，确保集群状态与期望状态一致。
  • 包括节点控制器、复制控制器、端点控制器等。

2. 节点 (Node)

节点是 Kubernetes 集群中的工作机器，可以是物理机或虚拟机。

• Kubelet：

  • 运行在每个节点上，负责与 Kubernetes API Server 通信，处理 Pods 的生命周期。
  • 确保容器在节点上运行。

• Kube Proxy：

  • 负责维护网络规则，以使服务能够访问 Pods。
  • 提供负载均衡功能，使请求能够路由到对应的 Pod。

• Container Runtime：

  • 运行容器的实际软件，例如 Docker、containerd 等。

3. 工作负载 (Workloads)

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

• Pod：

  • Kubernetes 中最小的可调度单位，一个 Pod 可以包含一个或多个容器。

• Replication Controller / ReplicaSet：

  • 确保特定数量的 Pod 实例在运行。

• Deployment：

  • 管理 Pod 的部署、升级和回滚等操作。

• StatefulSet：

  • 管理有状态应用程序，提供持久化存储和唯一性。

• DaemonSet：

  • 确保在集群中的每个节点上都运行一个 Pod。

4. 服务 (Services)

服务是 Kubernetes 中的一种抽象，定义了一组 Pod 的访问策略。

• ClusterIP：

  • 提供集群内部的虚拟 IP，供内部服务访问。

• NodePort：

  • 通过集群节点的 IP 和指定端口，允许外部访问服务。

• LoadBalancer：

  • 结合云服务提供商，自动配置外部负载均衡器。

5. 配置和存储

• ConfigMap：

  • 用于存储非敏感的配置数据。

• Secret：

  • 用于存储敏感信息，如密码、令牌等。

• PersistentVolume (PV) 和 PersistentVolumeClaim (PVC)：

  • PV 是集群中的存储资源，PVC 是用户对存储资源的请求。

组件之间的关系

• API Server 是所有组件的中心，所有操作都通过它进行。
• etcd 存储着集群的所有状态和配置数据，供 API Server 和其他组件访问。
• Scheduler 和 Controller Manager 依赖于 API Server 来获取集群状态，并对 Pods 和节点进行调度和管理。
• Kubelet 负责管理节点上的 Pods，并通过 API Server 更新 Pod 状态。
• Kube Proxy 确保 Pods 和服务之间的网络通信。

总结

Kubernetes 由多个相互依赖的组件组成，这些组件共同工作以管理容器化应用的生命周期和状态。理解这些组件及其关系，有助于更好地使用和管理 Kubernetes 集群。

POD创建流程

创建一个 Kubernetes Pod 的流程涉及多个步骤，从用户发出请求到 Pod 实际运行在节点上。下面是创建 Pod 的详细流程：

1. 用户提交 Pod 定义

用户通过 kubectl 命令行工具、Kubernetes API 或者通过编写 YAML 文件来定义 Pod 的规格。例如，用户可以创建一个名为 my-pod.yml 的文件，内容如下：

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: nginx

2. API Server 接收请求

• 用户通过命令 kubectl apply -f my-pod.yml 提交 Pod 定义。
• kubectl 将这个请求发送到 Kubernetes API Server。
• API Server 验证请求的合法性，包括检查 YAML 文件的语法、字段是否正确等。

3. 更新 etcd 存储

• API Server 将 Pod 的元数据（如名称、状态、规格等）存储到 etcd。
• etcd 是一个高可用的分布式键值存储，用于持久化 Kubernetes 的状态。

4. 调度器调度 Pod

• Scheduler 监视未被调度的 Pod，并根据集群的资源利用情况（CPU、内存等）、亲和性和反亲和性等调度策略，选择一个合适的节点来运行 Pod。
• 调度决策后，Scheduler 将 Pod 的目标节点信息更新到 API Server。

5. Kubelet 在节点上创建 Pod

• Kubelet 运行在每个节点上，它会定期向 API Server 查询待处理的 Pod。
• 当 Kubelet 发现有新的 Pod 分配到它的节点上时，它将根据 Pod 的定义来创建相应的容器。
• Kubelet 通过容器运行时（如 Docker、containerd）启动容器，并确保容器的状态与 Pod 定义一致。

6. 容器启动

• 容器启动后，Kubelet 监控容器的状态，并将状态信息报告回 API Server。
• 一旦容器成功启动并运行，Pod 的状态将被更新为 Running。

7. 服务发现和网络

• Kube Proxy 会配置网络规则，以便其他服务能够通过 Pod 的虚拟 IP 地址访问这个 Pod。
• 如果 Pod 定义了服务（如 ClusterIP），Kube Proxy 会在集群内部创建相应的网络服务。

8. 监控和管理

• 用户可以通过 kubectl get pods 命令查看 Pod 的状态，Kubernetes 将保持 Pod 的健康监控。
• 如果 Pod 或容器出现故障，Kubelet 会尝试重启容器，确保 Pod 的期望状态得到满足。

总结

整个 Pod 创建流程涉及多个组件的协作，包括用户提交请求、API Server 处理请求、etcd 存储状态、调度器选择节点、Kubelet 启动容器等。这些组件的协调确保了 Kubernetes 能够自动化地管理容器化应用的生命周期。

#探针的类型
Kubernetes 中的探针（Probe）是用于检查容器的健康状况和就绪状态的机制。它们可以帮助 Kubernetes 确定容器何时可以接收流量或何时需要重启。Kubernetes 支持以下三种主要类型的探针：

1. Liveness Probe（存活探针）

• 目的：检查容器是否仍在运行。如果探测失败，Kubernetes 会杀死容器并根据容器的重启策略重新启动它。

• 适用场景：适用于检测应用程序是否死锁、陷入无响应状态或其他导致容器不再有效的情况。

• 配置示例：

  livenessProbe:
    httpGet:
      path: /healthz
      port: 8080
    initialDelaySeconds: 30
    periodSeconds: 10

2. Readiness Probe（就绪探针）

• 目的：检查容器是否准备好接收流量。如果探测失败，Kubernetes 将不会将流量路由到该容器。

• 适用场景：适用于检测应用程序是否已完成初始化或准备好处理请求。适合用于长时间启动的应用程序。

• 配置示例：

  readinessProbe:
    exec:
      command: ["cat", "/tmp/healthy"]
    initialDelaySeconds: 5
    periodSeconds: 5

3. Startup Probe（启动探针）

• 目的：用于在容器启动期间检测应用是否已准备好。如果探测失败，Kubernetes 会杀死容器并根据重启策略重启它。与 liveness probe 不同的是，startup probe 仅在容器启动时运行，适合长时间启动的应用程序。

• 适用场景：适用于需要长时间初始化的应用程序，确保在应用程序完全启动并正常运行之前不会触发 liveness probe。

• 配置示例：

  startupProbe:
    tcpSocket:
      port: 8080
    initialDelaySeconds: 30
    periodSeconds: 10

探针的类型对比

结论

探针是 Kubernetes 重要的健康检查机制，能帮助保持应用程序的可靠性和可用性。根据应用程序的特性和需求，适当使用这三种探针可以有效管理容器的生命周期。

探针如何工作的

http 和tcp是 如何判断成功的。

pod起不来有哪些原因

当 Kubernetes Pod 无法启动时，可能由多种原因造成。以下是常见的原因及其对应的排查步骤：

1. 容器镜像问题

• 原因：指定的容器镜像不存在或无法拉取。
• 排查步骤：
  • 查看 Pod 的事件和状态，使用以下命令：

    kubectl describe pod <pod-name>

  • 检查镜像名称和标签是否正确。
  • 确认集群是否可以访问镜像仓库，使用 kubectl logs <pod-name> 查看相关日志。

2. 资源不足

• 原因：节点没有足够的资源（CPU、内存）来调度 Pod。
• 排查步骤：
  • 使用以下命令检查节点的资源使用情况：

    kubectl describe nodes

  • 确认 Pod 的资源请求和限制设置是否合适，调整 Pod 的请求值，或者添加更多节点。

3. 环境变量和配置问题

• 原因：缺少必要的环境变量或配置文件。
• 排查步骤：
  • 检查 Pod 配置文件，确保所有必要的环境变量和配置文件都已设置。
  • 如果使用 ConfigMap 或 Secret，确认它们是否存在且内容正确。

4. 依赖服务不可用

• 原因：Pod 依赖的其他服务（如数据库、消息队列）未能启动。
• 排查步骤：
  • 检查依赖服务的状态，确认它们是否运行正常。
  • 查看 Pod 日志，确保应用能连接到依赖服务。

5. 健康检查失败

• 原因：Pod 的探针（Liveness、Readiness）配置不正确，导致启动失败。
• 排查步骤：
  • 检查探针的配置，确保端口和路径正确。
  • 使用以下命令查看 Pod 的状态：

    kubectl get pod <pod-name>

  • 调整探针的参数（如时间、失败阈值等）。

6. 网络问题

• 原因：网络策略或 CNI 插件配置错误导致无法连接。
• 排查步骤：
  • 检查网络策略是否正确，确保允许 Pod 之间的通信。
  • 查看 CNI 插件的状态，使用以下命令：

    kubectl get pods -n kube-system

  • 确认网络插件配置是否正确。

7. 挂载卷问题

• 原因：PersistentVolume（PV）或 PersistentVolumeClaim（PVC）未成功绑定。
• 排查步骤：
  • 检查 PVC 的状态，确认是否绑定成功：

    kubectl get pvc

  • 查看 PV 的状态，确保其可用且未被其他 Pod 占用。

8. Pod 规格问题

• 原因：Pod 规格配置错误。
• 排查步骤：
  • 使用以下命令查看 Pod 详细信息，确认其规范是否正确：

    kubectl get pod <pod-name> -o yaml

  • 确认 Pod 的启动命令、参数、容器端口等配置无误。

9. 调度问题

• 原因：调度器无法将 Pod 调度到节点上。
• 排查步骤：
  • 使用以下命令查看 Pod 的事件信息，确认是否有调度错误：

    kubectl describe pod <pod-name>

  • 检查是否设置了 Node Affinity 或 Taints/Tolerations，可能导致调度失败。

10. 安全上下文问题

• 原因：Pod 运行需要的权限不足。
• 排查步骤：
  • 检查 Pod 的安全上下文（securityContext），确认必要的权限（如特权模式、用户和组 ID 等）是否正确设置。

总结

排查 Pod 无法启动的原因时，可以从容器镜像、资源分配、环境变量、依赖服务、健康检查、网络配置、挂载卷、Pod 规格、调度策略以及安全上下文等多个方面进行系统检查。通过上述步骤，通常可以识别出问题所在并采取相应的解决措施。

如何修改service的端口

在 Kubernetes 中修改 Service 的 nodePort 端口需要一些步骤，以确保在不中断服务的情况下完成。我们可以通过以下方法完成端口修改。

前提条件

• 确保有适当的权限可以编辑 Kubernetes Service。
• 备份现有 Service 配置，以防在操作中出现意外情况。

操作步骤

步骤 1：备份现有的 Service 配置

1. 使用 kubectl get 命令获取现有的 Service 配置，并将其导出到 YAML 文件。

   kubectl get service <service-name> -n <namespace> -o yaml > service-backup.yaml

   替换 <service-name> 和 <namespace> 为实际的 Service 名称和命名空间。

步骤 2：删除现有的 Service（非破坏性删除）

1. 确保 Service 是没有 clusterIP 类型依赖的（NodePort 不依赖于集群 IP）。

2. 记录现有的 nodePort 和其他配置，特别是需要修改的端口号。

3. 使用以下命令删除 Service：

   kubectl delete service <service-name> -n <namespace>

步骤 3：修改 YAML 文件中的 nodePort

1. 打开之前备份的 service-backup.yaml 文件。

2. 在 spec.ports 下找到 nodePort 字段，将端口号改为需要的端口。例如：

   spec:
     ports:
       - port: 80
         targetPort: 80
         nodePort: 30080  # 修改为新的端口号

步骤 4：重新创建 Service

1. 使用修改后的 YAML 文件重新创建 Service。

   kubectl apply -f service-backup.yaml

2. 使用以下命令确认新的 nodePort 是否已应用成功。

   kubectl get service <service-name> -n <namespace>

步骤 5：验证 Service 的新端口

1. 使用 kubectl describe service 命令检查 Service 的配置，确认 nodePort 端口已更改。

   kubectl describe service <service-name> -n <namespace>

2. 测试新的 nodePort 是否能正常访问。例如，如果服务暴露在某个节点的 IP 上，可以通过该节点 IP 和新的 nodePort 进行访问测试：

   curl http://<node-ip>:<new-nodePort>

步骤 6：清理和检查

1. 确认新 nodePort 配置正常，且不再需要旧的备份文件，可以将其删除。
2. 验证服务没有中断，且应用成功通过新的端口进行访问。

注意事项

• 确保新的 nodePort 不冲突或被其他服务占用。
• 若更改的 nodePort 是关键应用中的端口，建议安排在业务低峰期执行。
• 如果使用 kubectl edit service <service-name> 修改在线配置，需要谨慎，因为直接在线编辑可能导致配置丢失。