Pod

Pod 是 Kubernetes中最小的可部署单元， 中文可以翻译为 “容器组”。 它是用于承载和管理容器的抽象层。 一个 Pod 可以包含一个或多个紧密关 联的容器， 它们共享相同的网络命名空间、 IP 地址和存储卷， 并在同一个宿 主机上运行。

Node

Node是一个运行着Kubernetes节点软件的物理机器或虚拟机。 每个Node 负责运行Pod中的容器， 并由Kubernetes控制平面管理。 Node是Kubernetes集群中的工作节点， 它实际执行应用程序工作负载并提 供运行环境。

kubelet

kubelet 是运行在每个节点上的一个服务(不作为pod)，它负责维护和管理每个节点上的Pod,确保它们按照预期运行。 它与kubernetes的控制平面进行通信，确保节点上的Pod和集群上的其他组件保持同步。

kube-proxy

kubernetes中的网络核心组件， 作为pod运行在每个节点上，实现了服务暴露和转发等网络功能。 应用最多的是iptables和ipvs模式。

Master / control plane

Kubernetes里的master指的是集群控制节点，一般情况下，该节点又称control plane （控制平面, 如果是多个节点共同组成，他们一起组成了控制平面）。该节点一般会通过节点自污避免工作任务调度（除非显式指定）。基本上所有的kubernetes的控制命令都会发给它，他负责具体的执行过程。

在云托管厂商的master节点是有多副本机制来保障高可用（eks等平台都会托管master节点，对用户透明），具体来说控制平面中的api-server组件通过负载均衡分发流量到健康的实例上，而etcd 和 kube-scheduler/kube-controller-manager 通过Leader选举实现高可用，同一时刻只有一个Leader负责工作，当Leader所在节点故障时，其余节点会竞争上岗。

api-server

api-server是集群的核心，是k8s的最重要组件，它是声明式api （区别于命令式api）的关键。它的核心功能是提供了kubernetes的各类资源对象的增删改查等http rest接口。

etcd

etcd 是兼具一致性和高可用性的键值数据库，用于服务发现和配置中心。 采用raft一致性算法

controller-manager

保证集群中各种资源的状态于用户定义的期待状态（spec）保持一致。

kube-scheduler

负责整个集群的资源调度，将pod调度到最优的工作节点上面去，从而更加合理的利用集群资源（如果没有满足要求的节点，该pod会一直处于pending状态）。

Deployment

一种Pod的负载控制器，是ReplicaSet的高级抽象，进一步的封装，只有Deployment是特殊的负载控制器依赖了更为底层的控制器，它可以指挥kubernetes如何创建和更新部署的应用，创建Deployment后，kubernetes master 会将应用调度到集群的各个节点上。

适合无需持久化数据、无依赖顺序的副本（如无状态服务）。

StatefulSet

一种Pod的负载控制器，和Deployment同级关系，它可以为Pod提供持久存储和持久标识符。（用于管理有状态的应用，比如数据库，但是k8s对有状态应用的支持并不是最完美的，通常企业应用选择使用云厂商的云数据库，而不是使用k8s的云原生数据库。 ）

适合需要稳定网络标识、持久化存储或有序部署的集群（如 MySQL、Kafka）。

ReplicaSet

一种Pod的负载控制器，是Deployment的底层控制器。 负责保证Pod的数量是指定的。

DaemonSet

确保全部（或者指定）节点上运行一个Pod的副本。 当有节点加入集群时候，也为他们增加一个Pod副本。

Service

service使用标签选择算符（Selectors）将运行在一个或者一组Pod的应用公开为网络服务的方法（一般是集群内部使用）。

• Service：解决“如何访问服务”的问题，提供基础负载均衡。
• Ingress：解决“如何灵活管理外部流量”的问题，提供高级路由能力。
• 搭配使用：通常将 Ingress 作为流量入口，路由到不同的 Service，再由 Service 分发到 Pod。

典型工作流程

1. Service 定义如何访问一组 Pod（如 backend:8080）。
2. Ingress 定义规则（如 example.com/api -> backend:8080）。
3. Ingress 控制器监听 Ingress 规则，动态配置反向代理（如 Nginx）。
4. 外部流量通过 Ingress 控制器进入集群，按规则路由到对应的 Service。

Ingress

我们可以通过 NodePort 和 LoadBalancer 这两种类型的 Service 让应用程序暴露到集群外部，不过这两种方式都有各自的问题：

• NodePort 会在所有节点上暴露端口，外部应用需要知道集群内部节点的 IP 才能访问，一旦集群节点发生变化，外部应用也会受影响，可用性无法保证；而且端口的范围是受限的，默认只能使用 30000 到 32767 之间的端口，外部应用使用起来会感觉怪怪的；另外，每个端口只能对应一个 Service，如果 Service 数量过多，暴露的端口也会过多，不仅安全性难以保障，而且管理起来也会很麻烦；
• LoadBalancer 依赖于外部负载均衡器作为流量的入口，它在云平台中使用非常广泛，一般使用云供应商提供的 LB 服务，它会有一个自己的 IP 地址来转发所有流量，不过要注意的是，你暴露的每个 Service 都对应一个 LB 服务，而每个 LB 都需要独立付费，如果你暴露的 Service 很多，这将是非常昂贵的。

可以将 Ingress 理解为 Service 的网关，它是所有流量的入口，通过 Ingress 我们就能以一个集群外部可访问的 URL 来访问集群内部的 Service。

你必须拥有一个 Ingress 控制器 才能满足 Ingress 的要求。仅创建 Ingress 资源本身没有任何效果。

你可能需要部署一个 Ingress 控制器，例如 ingress-nginx。 你可以从许多 Ingress 控制器中进行选择。

• Ingress Controller：通常安装在独立的命名空间（例如 ingress-nginx），负责监听并处理 所有命名空间 中的 Ingress 资源（除非明确配置了过滤）。
• Ingress 资源：可以部署在任意命名空间（例如 default 或你的应用命名空间）。
• 通常情况下， Ingress Controller 会扫描所有的命名空间的Ingress资源。

所以首先要定义一个type是 LoadBalancer 的 service。该服务称为 Ingress控制器服务。 对应内容是 ingress-nginx 或者traefik 这样的 ingress controller应用。

# minikube 环境快速安装 ingress 控制器服务和对应 pod
minikube addons enable ingress

然后创建一个 Ingress 对象，里面存储路由规则。

# example-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /  # 可选：路径重写
spec:
  tls:
    - hosts:
        - example.com
      secretName: example-tls  # TLS 证书（需提前创建 Secret）
  rules:
    - host: example.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: backend
                port:
                  number: 80

Endpoint

Endpoint（端点） 是 Service 和实际 Pod 实例之间的桥梁。它记录了 Service 关联的 Pod 的具体网络地址（IP:Port），是 Service 实现流量转发的核心机制。

• 自动模式：Service 通过 selector 关联 Pod 时，Endpoint 由 Kubernetes 自动维护。
• 手动模式：无 selector 的 Service 可手动配置 Endpoint，指向外部服务。
• 排查问题：若 Service 无法访问，可通过 kubectl describe endpoints 检查后端 Pod 是否正常。

ConfigMap

ConfigMap 是 Kubernetes 管理非敏感配置的核心工具。实现配置与代码分离，提升应用的可移植性和可维护性。

Secret

出于职责分离，设计了更高级的敏感配置管理工具。 可以对敏感配置进行加密，并且对权限更为敏感。

• ConfigMap 的不足：

  • 明文存储，不适合敏感数据。
  • 无自动加密机制（即使第三方工具可加密，但需手动操作）。

• Secret 的优势：

  • Base64 编码可避免纯明文直接暴露（但非严格加密）。
  • 支持静态加密（需配置 Kubernetes 集群的 Secret 加密功能，使用 KMS Provider（如AWS KMS、GCP Cloud KMS））。
  • 挂载为内存文件（tmpfs），减少磁盘泄露风险。
  • 通过RBAC限制Secret的读取权限。

namespace

命名空间将同一集群中的资源划分为互相隔离的组，以便进行分类管理。

delete namespace 可以将该命名空间资源全部回收。

持久化

PV 、 PVC 和 StorageClass

PV 持久化卷， PVC 持久化卷请求， StorageClass 负责接收PVC来为其创建对应的PV，当其不存在的时候，需要手动指定PV。

我们可以用 「酒店订房」 的比喻来理解 PV 和 PVC 的关系：

• PV（PersistentVolume）：是 酒店的房间（实际存在的存储资源）。
• PVC（PersistentVolumeClaim）：是 用户的订房请求（声明需要什么样的存储资源）。

我们在使用云厂商的持久化卷的时候，是不需要关心PV的，我们写好PVC，云厂商就会自动帮我们创建符合要求的PV来供我们使用。 这是通过动态供应来完成的,也就是云厂商默认写了一个StorageClass,例如EKS中

kubectl get storageclass


NAME            PROVISIONER             RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION
gp2 (default)   kubernetes.io/aws-ebs   Delete          WaitForFirstConsumer   true

coreDNS

在 Kubernetes 的默认 DNS 设置中，不同命名空间（Namespace）下的服务可以通过完整的 DNS 名称相互解析和通信，但需要显式指定目标服务的命名空间。相同命名空间则可以使用短名称。根因也很简单就是在Pod内部的 /etc/resolv.conf文件可以看出

nameserver 10.96.0.10
search kk.svc.cluster.local svc.cluster.local cluster.local

nameserver 指向的是 dns的服务ip地址。 search 可以看出优先匹配当前pod所在命名空间。