Kubernetes 核心概念与原理

Kubernetes 基础架构

Kubernetes 作为容器编排的事实标准，其基础架构设计精巧，由多个核心组件协同工作，以实现容器化应用的高效管理。

控制平面组件

1. kube - apiserver
   • 功能概述：kube - apiserver 是 Kubernetes 集群的前端接口，负责接收并处理来自客户端的请求，对集群的资源进行增删改查操作。它是整个集群的控制中心枢纽，所有对集群状态的改变都要通过它。
   • 原理深入：它基于 RESTful API 设计，使用 etcd 作为后端存储来持久化集群状态。例如，当用户想要创建一个新的 Pod 时，会向 kube - apiserver 发送一个 POST 请求，请求体包含 Pod 的定义信息。kube - apiserver 首先会对请求进行认证和授权，确保请求者有足够的权限执行该操作。然后，它将 Pod 的定义信息存储到 etcd 中，并通知其他组件进行相应的处理。
   • 代码示例（使用 kubectl 与 kube - apiserver 交互）：

# 创建一个简单的 Pod
kubectl apply -f pod.yaml

这里 pod.yaml 是定义 Pod 的 YAML 文件，通过 kubectl 工具发送请求到 kube - apiserver，进而创建 Pod。

2. etcd
   • 功能概述：etcd 是一个高可用的键值对存储，用于保存 Kubernetes 集群的所有持久化数据。它存储了集群状态，包括 Pod、Service、Namespace 等资源的定义和状态。
   • 原理深入：etcd 使用 Raft 一致性算法来保证数据的一致性和高可用性。在一个 etcd 集群中，有多个节点，其中一个节点会成为领导者（Leader），其他节点为跟随者（Follower）。所有的写操作都要先经过 Leader，Leader 将写操作日志复制到 Follower 节点，当大多数节点（超过半数）确认收到日志后，Leader 才会提交该日志，从而保证数据的一致性。
   • 代码示例（使用 etcdctl 工具操作 etcd）：

# 安装 etcdctl
sudo apt - get install etcdctl

# 查看 etcd 中存储的键值对
etcdctl get / --prefix

这可以查看 etcd 中所有以 / 开头的键值对，也就是 Kubernetes 集群相关的资源信息。

3. kube - scheduler
   • 功能概述：kube - scheduler 负责将新创建的 Pod 调度到合适的 Node 上运行。它会根据一系列的调度策略和算法，综合考虑 Node 的资源状况、Pod 的资源需求、节点的标签等因素来做出决策。
   • 原理深入：它通过监听 kube - apiserver 中未绑定到 Node 的 Pod 资源对象，然后按照预定的调度策略进行评估。例如，有一个 Pod 需要 2GB 的内存和 1 个 CPU 核心，kube - scheduler 会遍历所有的 Node，筛选出满足资源需求的 Node，再根据其他策略（如节点亲和性、反亲和性等）进一步选择最合适的 Node 来运行该 Pod。
   • 代码示例（自定义调度策略扩展）： 在 Kubernetes 中，可以通过编写自定义调度器来扩展调度策略。下面是一个简单的基于 Node 标签的自定义调度器示例代码片段（使用 Go 语言）：

package main

import (
    "fmt"
    "k8s.io/api/core/v1"
    "k8s.io/client - go/kubernetes"
    "k8s.io/client - go/tools/clientcmd"
)

func main() {
    kubeconfig := "/path/to/your/kubeconfig"
    config, err := clientcmd.BuildConfigFromFlags("", kubeconfig)
    if err!= nil {
        panic(err.Error())
    }

    clientset, err := kubernetes.NewForConfig(config)
    if err!= nil {
        panic(err.Error())
    }

    pods, err := clientset.CoreV1().Pods("default").List(context.TODO(), metav1.ListOptions{})
    if err!= nil {
        panic(err.Error())
    }

    for _, pod := range pods.Items {
        if pod.Spec.NodeName == "" {
            // 自定义调度逻辑，根据 Node 标签选择 Node
            nodes, err := clientset.CoreV1().Nodes().List(context.TODO(), metav1.ListOptions{})
            if err!= nil {
                panic(err.Error())
            }
            for _, node := range nodes.Items {
                if node.Labels["custom - label"] == "desired - value" {
                    pod.Spec.NodeName = node.Name
                    _, err := clientset.CoreV1().Pods("default").Update(context.TODO(), &pod, metav1.UpdateOptions{})
                    if err!= nil {
                        fmt.Println(err)
                    }
                    break
                }
            }
        }
    }
}

这段代码实现了一个简单的自定义调度逻辑，根据 Node 的 custom - label 标签来调度 Pod。

4. kube - controller - manager
   • 功能概述：kube - controller - manager 包含多个控制器，每个控制器负责特定的集群功能，如节点控制器（Node Controller）、副本控制器（Replication Controller）、端点控制器（Endpoints Controller）等。这些控制器通过监控集群状态，将实际状态与期望状态进行比较，并进行相应的调整，以确保集群始终处于期望的状态。
   • 原理深入：以副本控制器为例，它会持续监控集群中 Pod 的副本数量。如果实际副本数量低于期望的副本数量，它会创建新的 Pod；如果实际副本数量高于期望数量，它会删除多余的 Pod。这个过程是通过与 kube - apiserver 交互，查询和修改 Pod 的资源对象来实现的。
   • 代码示例（创建一个简单的自定义控制器）： 使用控制器管理器的框架，可以编写自定义控制器。以下是一个简单的使用 Go 语言和 Kubernetes 客户端库编写的自定义控制器示例代码片段：

package main

import (
    "context"
    "fmt"
    "k8s.io/apimachinery/pkg/api/errors"
    "k8s.io/apimachinery/pkg/runtime"
    "k8s.io/client - go/kubernetes"
    "k8s.io/client - go/tools/controller"
    "k8s.io/client - go/tools/cache"
    "k8s.io/client - go/tools/clientcmd"
)

func main() {
    kubeconfig := "/path/to/your/kubeconfig"
    config, err := clientcmd.BuildConfigFromFlags("", kubeconfig)
    if err!= nil {
        panic(err.Error())
    }

    clientset, err := kubernetes.NewForConfig(config)
    if err!= nil {
        panic(err.Error())
    }

    // 创建一个 Informer，用于监听 Pod 资源的变化
    podInformer := cache.NewSharedIndexInformer(
        &cache.ListWatch{
            ListFunc: func(options metav1.ListOptions) (runtime.Object, error) {
                return clientset.CoreV1().Pods("default").List(context.TODO(), options)
            },
            WatchFunc: func(options metav1.ListOptions) (watch.Interface, error) {
                return clientset.CoreV1().Pods("default").Watch(context.TODO(), options)
            },
        },
        &v1.Pod{},
        0,
        cache.Indexers{},
    )

    controller.NewController(
        controller.ControllerOptions{
            Informer: podInformer,
            Process: func(obj interface{}) error {
                pod, ok := obj.(*v1.Pod)
                if!ok {
                    return fmt.Errorf("unexpected object type: %T", obj)
                }
                // 自定义控制器逻辑，例如打印 Pod 状态变化
                fmt.Printf("Pod %s status changed to %s\n", pod.Name, pod.Status.Phase)
                return nil
            },
        },
    ).Run(context.TODO().Done())
}

这段代码创建了一个简单的自定义控制器，监听默认 Namespace 中 Pod 的状态变化并打印相关信息。

节点组件

1. kubelet
   • 功能概述：kubelet 是运行在每个 Node 上的代理，负责与 kube - apiserver 进行通信，接收并执行调度到该节点的 Pod 的创建、删除、启动等任务。它还负责监控 Pod 和容器的状态，并向 kube - apiserver 报告节点的资源使用情况。
   • 原理深入：kubelet 通过与容器运行时（如 Docker、Containerd 等）进行交互来管理容器。当 kubelet 接收到创建 Pod 的任务时，它会根据 Pod 的定义，调用容器运行时创建相应的容器，并配置网络和存储等资源。例如，对于一个包含多个容器的 Pod，kubelet 会按照 Pod 定义的顺序依次启动这些容器，并确保它们之间的网络和存储共享等配置正确。
   • 代码示例（查看 kubelet 状态）：

# 在 Node 节点上查看 kubelet 状态
systemctl status kubelet

这可以查看 kubelet 服务的运行状态，包括是否正在运行、启动时间等信息。

2. kube - proxy
   • 功能概述：kube - proxy 运行在每个 Node 上，负责实现 Kubernetes Service 的网络代理功能。它通过维护网络规则，将发往 Service 的流量转发到对应的 Pod 上，从而实现服务发现和负载均衡。
   • 原理深入：kube - proxy 可以使用多种模式来实现流量转发，如 iptables 模式和 IPVS 模式。在 iptables 模式下，kube - proxy 会根据 Service 和 Endpoints 的变化，动态生成 iptables 规则。例如，当有一个新的 Service 创建时，kube - proxy 会创建相应的 iptables 规则，将发往 Service IP 和端口的流量随机转发到 Service 对应的 Pod IP 和端口上。在 IPVS 模式下，kube - proxy 利用 Linux 的 IPVS 模块来实现更高效的负载均衡，IPVS 基于内核态运行，性能比 iptables 模式更好。
   • 代码示例（查看 kube - proxy 配置）：

# 查看 kube - proxy 的配置文件
cat /var/lib/kube - proxy/config.conf

这可以查看 kube - proxy 的当前配置，包括运行模式、集群 CIDR 等信息。

Kubernetes 资源对象

Kubernetes 使用资源对象来管理集群中的各种实体，这些资源对象构成了应用在 Kubernetes 上运行的基础。

Pod

1. 概念：Pod 是 Kubernetes 中最小的可部署和可管理的计算单元，它可以包含一个或多个紧密相关的容器。这些容器共享网络命名空间、存储卷等资源，它们被视为一个整体进行调度和管理。
2. 原理：从实现角度看，Pod 是通过 Linux 命名空间和控制组（cgroups）来实现容器之间的资源隔离和共享的。在同一个 Pod 中的容器共享网络命名空间，意味着它们可以通过 localhost 进行通信，并且拥有相同的 IP 地址和端口空间。例如，一个 Web 应用的 Pod 可能包含一个后端 API 容器和一个前端 UI 容器，它们可以通过 localhost 进行内部通信，而不需要通过外部网络。同时，Pod 中的容器可以共享存储卷，这样容器之间可以共享数据。
3. 代码示例（创建 Pod）： 以下是一个简单的 Pod 定义 YAML 文件 pod - example.yaml：

apiVersion: v1
kind: Pod
metadata:
  name: my - pod
spec:
  containers:
  - name: my - container
    image: nginx:1.19.10
    ports:
    - containerPort: 80

通过 kubectl apply -f pod - example.yaml 命令即可创建该 Pod。

Deployment

1. 概念：Deployment 是一种用于管理 Pod 副本数量和更新策略的资源对象。它提供了一种声明式的方式来定义应用的期望状态，Kubernetes 会自动将实际状态调整为期望状态。
2. 原理：Deployment 通过 ReplicaSet 来管理 Pod 的副本。当创建一个 Deployment 时，它会首先创建一个 ReplicaSet，ReplicaSet 负责确保指定数量的 Pod 副本始终运行。例如，如果 Deployment 定义的副本数量为 3，ReplicaSet 会监控集群中 Pod 的数量，如果少于 3 个，就会创建新的 Pod；如果多于 3 个，就会删除多余的 Pod。在进行更新时，Deployment 支持滚动更新策略，它会逐步替换旧版本的 Pod 为新版本的 Pod，以确保服务的连续性。
3. 代码示例（创建 Deployment）： 以下是一个简单的 Deployment 定义 YAML 文件 deployment - example.yaml：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my - deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my - app
  template:
    metadata:
      labels:
        app: my - app
    spec:
      containers:
      - name: my - container
        image: nginx:1.19.10
        ports:
        - containerPort: 80

通过 kubectl apply -f deployment - example.yaml 命令创建该 Deployment，Kubernetes 会自动创建 3 个运行 nginx:1.19.10 镜像的 Pod。

Service

1. 概念：Service 为一组功能相同的 Pod 提供了一个稳定的网络入口，它抽象了 Pod 的动态 IP 地址，使得其他 Pod 或外部客户端可以通过 Service 来访问这些 Pod，而无需关心 Pod 的具体 IP 地址和数量变化。
2. 原理：Service 实现了服务发现和负载均衡功能。当创建一个 Service 时，Kubernetes 会为其分配一个虚拟的 Cluster IP（仅在集群内部可访问），并且会在 etcd 中记录 Service 与对应的 Pod 的 Endpoints 的映射关系。kube - proxy 会根据这些信息在每个 Node 上配置网络规则，将发往 Service Cluster IP 和端口的流量负载均衡到对应的 Pod 上。例如，有一个名为 my - service 的 Service，它对应一组运行 Web 应用的 Pod，其他 Pod 可以通过 my - service:80 来访问这些 Web 应用，而无需知道具体 Pod 的 IP 地址。
3. 代码示例（创建 Service）： 以下是一个简单的 Service 定义 YAML 文件 service - example.yaml：

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

通过 kubectl apply -f service - example.yaml 命令创建该 Service，它会将发往 my - service:80 的流量负载均衡到具有 app: my - app 标签的 Pod 上。

Namespace

1. 概念：Namespace 是 Kubernetes 提供的一种虚拟集群机制，它通过将集群资源划分为不同的逻辑空间，使得不同团队或项目可以在同一个物理集群上隔离地使用资源，避免命名冲突。
2. 原理：在 Kubernetes 内部，Namespace 是通过在资源对象的元数据中添加 namespace 字段来实现的。所有资源对象都属于某个 Namespace（默认属于 default Namespace）。不同 Namespace 中的资源对象名称可以相同，并且它们之间的资源访问受到权限控制。例如，开发团队和测试团队可以分别使用不同的 Namespace，开发团队在自己的 Namespace 中创建的 Pod、Service 等资源不会与测试团队的资源产生冲突。
3. 代码示例（创建 Namespace）： 以下是创建一个名为 my - namespace 的 Namespace 的 YAML 文件 namespace - example.yaml：

apiVersion: v1
kind: Namespace
metadata:
  name: my - namespace

通过 kubectl apply -f namespace - example.yaml 命令即可创建该 Namespace。

Kubernetes 调度与资源管理

Kubernetes 的调度和资源管理机制确保了 Pod 能够在合适的节点上运行，并合理分配节点资源。

调度策略

1. 默认调度策略
   • 资源匹配策略：Kubernetes 调度器首先会根据 Pod 的资源请求（如 CPU、内存等）来筛选出有足够资源的节点。例如，一个 Pod 请求 1GB 内存和 0.5 个 CPU 核心，调度器会遍历所有节点，排除那些内存小于 1GB 或 CPU 核心小于 0.5 的节点。
   • 节点亲和性与反亲和性：节点亲和性允许 Pod 倾向于调度到具有特定标签的节点上。例如，如果某些节点标记为 role: database，可以通过节点亲和性将数据库相关的 Pod 调度到这些节点上。反亲和性则相反，例如，可以设置 Pod 避免调度到与自身具有相同标签的其他 Pod 所在的节点上，以提高应用的可用性和容错性。
   • 污点（Taints）与容忍（Tolerations）：污点是节点上的标记，用于表示该节点不适合运行某些 Pod。例如，一个节点可能设置了 dedicated: special - team 的污点，只有具有相应容忍的 Pod 才能调度到该节点上。容忍是 Pod 上的配置，用于声明 Pod 可以容忍某些污点，从而可以调度到带有这些污点的节点上。
2. 自定义调度策略
   • 扩展调度器：可以通过编写自定义调度器来实现特定的调度逻辑。如前文提到的基于 Node 标签的自定义调度器示例，通过实现自定义的调度逻辑，可以满足一些特殊的业务需求。例如，对于某些对网络延迟敏感的应用，可以编写调度器将这些应用的 Pod 优先调度到距离数据源更近的节点上。
   • 调度插件：Kubernetes 还支持通过调度插件来扩展调度功能。调度插件可以在调度过程的不同阶段（如预选、优选等阶段）插入自定义的逻辑。例如，可以编写一个调度插件，在优选阶段根据节点的网络带宽情况对节点进行打分，将 Pod 优先调度到网络带宽高的节点上。

资源管理

1. 资源请求与限制
   • 资源请求：在 Pod 的定义中，可以为容器设置资源请求，如 CPU 和内存。例如：

apiVersion: v1
kind: Pod
metadata:
  name: resource - pod
spec:
  containers:
  - name: my - container
    image: nginx:1.19.10
    resources:
      requests:
        cpu: "250m"
        memory: "512Mi"

这里 250m 表示 0.25 个 CPU 核心，512Mi 表示 512 兆字节的内存。Kubernetes 调度器会根据这些请求来选择合适的节点。

• 资源限制：同样在 Pod 定义中，可以设置资源限制，防止容器使用过多的资源。例如：

apiVersion: v1
kind: Pod
metadata:
  name: resource - pod
spec:
  containers:
  - name: my - container
    image: nginx:1.19.10
    resources:
      requests:
        cpu: "250m"
        memory: "512Mi"
      limits:
        cpu: "500m"
        memory: "1Gi"

这里容器最多可以使用 0.5 个 CPU 核心和 1 吉字节的内存。如果容器试图使用超过限制的资源，可能会被 Kubernetes 终止。 2. 资源配额

• Namespace 级别的资源配额：可以在 Namespace 中设置资源配额，限制该 Namespace 内所有 Pod 对资源的使用总量。例如，在一个 Namespace 中，可以限制 CPU 总量为 10 个核心，内存总量为 20GB。通过创建 ResourceQuota 对象来实现：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: my - quota
  namespace: my - namespace
spec:
  hard:
    pods: "10"
    requests.cpu: "10"
    requests.memory: "20Gi"
    limits.cpu: "10"
    limits.memory: "20Gi"

这将限制 my - namespace 中最多可以创建 10 个 Pod，并且所有 Pod 的 CPU 和内存请求及限制总和不能超过相应的值。

• 集群级别的资源管理：Kubernetes 集群管理员还可以通过设置集群级别的资源管理策略，如限制整个集群的资源使用，或者为不同的节点池分配不同的资源份额等，以确保整个集群的资源得到合理利用。

Kubernetes 网络与存储

网络和存储是 Kubernetes 中容器化应用正常运行的关键支撑。

网络

1. Pod 网络
   • 网络模型：Kubernetes 使用 Pod 网络模型，每个 Pod 都有自己独立的 IP 地址，并且同一个 Pod 内的容器共享网络命名空间。这意味着容器之间可以通过 localhost 进行通信，就像在同一台物理机上一样。例如，一个包含后端 API 容器和前端 UI 容器的 Pod，前端容器可以通过 localhost:8080 访问后端 API 容器提供的服务（假设后端 API 容器监听在 8080 端口）。
   • 网络实现：在实际实现中，有多种网络插件可以实现 Pod 网络，如 Flannel、Calico 等。以 Flannel 为例，它通过在每个 Node 上运行一个 flanneld 代理，使用 etcd 存储网络配置信息，为每个 Node 分配一个子网段，然后通过 VXLAN 或 UDP 等方式将不同 Node 上的 Pod 网络连接起来，实现 Pod 之间的跨节点通信。
2. Service 网络
   • Cluster IP：Service 的 Cluster IP 是一个虚拟的 IP 地址，仅在集群内部可访问。它通过 kube - proxy 实现负载均衡，将发往 Cluster IP 和端口的流量转发到对应的 Pod 上。例如，一个名为 my - service 的 Service，其 Cluster IP 为 10.96.0.10，端口为 80，当其他 Pod 访问 10.96.0.10:80 时，流量会被负载均衡到 my - service 对应的 Pod 上。
   • NodePort：除了 Cluster IP，Service 还可以通过 NodePort 方式暴露服务，使得外部客户端可以通过 Node 的 IP 地址和指定的 NodePort 来访问 Service。例如，将一个 Service 的 NodePort 设置为 30000，外部客户端可以通过 NodeIP:30000 来访问该 Service，流量会被转发到对应的 Pod 上。这种方式适用于简单的开发和测试环境，或者需要快速将服务暴露给外部的场景。
   • LoadBalancer：在云环境中，Kubernetes 可以通过 LoadBalancer 类型的 Service 自动创建云提供商的负载均衡器，将外部流量转发到 Service 对应的 Pod 上。例如，在 AWS 上，创建一个 LoadBalancer 类型的 Service 会自动创建一个 Elastic Load Balancing（ELB），将外部流量负载均衡到 Kubernetes 集群中的 Pod 上，实现高可用的对外服务。
3. 网络策略
   • 概念：网络策略用于定义 Pod 之间以及 Pod 与外部网络之间的网络访问规则。它通过标签选择器来指定目标 Pod，并定义允许或拒绝的流量规则。例如，可以创建一个网络策略，只允许具有 app: web 标签的 Pod 访问具有 app: api 标签的 Pod 的 8080 端口。
   • 实现：网络策略的实现依赖于网络插件，如 Calico 等。Calico 通过在每个 Node 上配置 iptables 规则来实现网络策略。例如，当创建一个允许特定 Pod 访问另一个 Pod 的网络策略时，Calico 会在相关 Node 上添加相应的 iptables 规则，允许符合条件的流量通过。

存储

1. Volume
   • 概念：Volume 是 Kubernetes 提供的一种用于在 Pod 中持久化数据或在容器之间共享数据的机制。它可以挂载到 Pod 内的一个或多个容器中，并且其生命周期独立于容器的生命周期。例如，一个数据库容器可以将数据存储在一个 Volume 中，即使容器被重新启动，数据也不会丢失。
   • 类型：Kubernetes 支持多种类型的 Volume，如 EmptyDir、HostPath、NFS、PersistentVolumeClaim 等。
     • EmptyDir：EmptyDir Volume 在 Pod 创建时被创建，当 Pod 被删除时，其中的数据也会被删除。它主要用于在同一个 Pod 内的容器之间共享临时数据。例如，一个日志收集容器和一个应用容器可以共享一个 EmptyDir Volume，应用容器将日志文件写入该 Volume，日志收集容器从该 Volume 中读取日志文件进行处理。
     • HostPath：HostPath Volume 允许将 Node 上的文件系统路径挂载到 Pod 中。这种类型的 Volume 适用于需要访问 Node 本地资源的场景，如在 Node 上存储配置文件，然后在 Pod 中挂载该文件进行读取。但使用 HostPath 时需要注意不同 Node 上路径的一致性问题。
     • NFS：NFS（Network File System）Volume 可以将 NFS 服务器上的共享目录挂载到 Pod 中。这使得多个 Pod 可以共享相同的数据，适用于需要在多个 Pod 之间共享数据的场景，如多个 Web 服务器 Pod 共享一个存储静态文件的 NFS 目录。
     • PersistentVolumeClaim：PersistentVolumeClaim（PVC）是用户对持久化存储的请求，它与 PersistentVolume（PV）绑定。PV 是集群管理员预先创建的存储资源，PVC 可以根据需求动态绑定到合适的 PV 上。例如，一个应用需要 10GB 的持久化存储，用户可以创建一个 PVC 请求 10GB 的存储，Kubernetes 会自动将其绑定到满足条件的 PV 上，然后将该 PV 挂载到 Pod 中。
2. 存储类（StorageClass）
   • 概念：存储类是 Kubernetes 提供的一种动态配置存储资源的机制。它允许集群管理员定义不同类型的存储资源模板，用户可以根据自己的需求选择合适的存储类来创建 PVC。例如，集群管理员可以定义一个高性能的 SSD 存储类和一个低成本的 HDD 存储类，用户可以根据应用对存储性能的要求选择相应的存储类来创建 PVC。
   • 工作原理：存储类通过 Provisioner 来动态创建 PV。Provisioner 是与存储后端（如 AWS EBS、GCE Persistent Disk 等）交互的插件。当用户创建一个 PVC 并指定了存储类时，Kubernetes 会调用该存储类对应的 Provisioner 来动态创建一个满足 PVC 需求的 PV，并将其绑定到 PVC 上。例如，对于 AWS EBS 存储类，Provisioner 会调用 AWS API 创建一个 EBS 卷，并将其挂载到合适的 Node 上，然后将该 EBS 卷作为 PV 绑定到 PVC 上。

通过深入理解 Kubernetes 的核心概念与原理，开发人员和运维人员能够更好地利用 Kubernetes 来构建、部署和管理容器化应用，充分发挥其在资源管理、调度、网络和存储等方面的强大功能，实现应用的高效运行和高可用性。