[面试] k8s面试题 2

---

核心组件

Kubernetes（K8s）是一个由多个组件组成的容器编排平台。以下是 Kubernetes 中一些核心组件的简要介绍：

kube-apiserver：Kubernetes API 服务器是整个集群的控制面板。它公开了 Kubernetes API，允许用户和其他组件与集群进行交互。

kube-controller-manager：Kubernetes 控制器管理器是一组负责运行集群级控制器的进程。控制器用于监视集群状态，并对期望状态和实际状态之间的差异进行调节，以确保集群中的组件达到所需的状态。

kube-scheduler：Kubernetes 调度器负责根据 Pod 的资源需求和节点的可用资源来选择合适的节点进行 Pod 的调度。调度器考虑诸多因素，如亲和性、反亲和性、节点亲和性等，以实现高效的调度策略。

kubelet：Kubernetes 的节点代理，运行在每个节点上。kubelet 负责管理节点上的容器和 Pod，它会与容器运行时（如 Docker）进行交互，确保 Pod 在节点上正确启动、停止和健康运行。

kube-proxy：Kubernetes 的网络代理，运行在每个节点上。kube-proxy 负责为 Service 提供服务发现和负载均衡功能，以及实现 Pod 之间的网络通信。

etcd：Kubernetes 使用 etcd 作为分布式键值存储，用于持久化集群的状态和元数据。etcd 提供了高可用性、一致性和可靠性的数据存储能力。

除了上述核心组件外，还有其他附加组件和工具，如：

kube-dns/coredns：为集群中的服务提供 DNS 解析功能，使得可以通过服务名称来访问其他服务或 Pod。
Ingress Controller：处理入站网络流量，并将其路由到适当的服务。
Dashboard：提供一个图形化的用户界面，用于管理和监控 Kubernetes 集群。
Prometheus：用于监视和警报的开源系统，用于收集和分析各种指标数据。
Container Runtime：Kubernetes 支持多种容器运行时，如 Docker、containerd、CRI-O 等。
这只是 Kubernetes 中一些核心和常见的组件，实际上还有更多组件和工具可以根据需求进行配置和部署。

---

1.什么是 Kubernetes 中的控制器（Controller）？请提供一些常见的控制器类型。

控制器是 Kubernetes 中负责管理、调度和操作资源的组件。它确保集群状态与期望状态一致。常见的控制器类型包括 ReplicaSet、Deployment、StatefulSet、DaemonSet、Job、CronJob 等。

---

2.请解释一下 Kubernetes 中的 Ingress 是什么，以及它的作用。

Ingress 是 Kubernetes 中的一种资源对象，用于提供对集群内服务的 HTTP 和 HTTPS 路由。它可以将外部流量路由到集群内的不同服务，并提供负载均衡、SSL 终止等功能。

Kubernetes 中的 Ingress 是一种 API 对象，用于公开集群中的服务。它提供了一种将外部流量路由到内部服务的方法，
可以根据不同的 URL 路径或主机名将请求发送到不同的服务端点。

要使用 Ingress，您需要满足以下条件：

1. 集群中运行一个支持 Ingress 控制器的 Kubernetes 集群。

2. 在 Ingress 控制器之上定义 Ingress 规则，指定如何路由流量和转发到服务。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress # 定义 Ingress 名称
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: / # 将 URL 重写
spec:
  rules:
    - host: example.com # 定义主机名
      http:
        paths:
          - path: /app1 # 路径为 /app1
            pathType: Prefix # 匹配前缀
            backend:
              service:
                name: app1-svc # 指定服务名称
                port:
                  name: app1-port # 指定服务端口名称
            annotations:
              description: "This rule routes traffic to app1."
          - path: /app2 # 路径为 /app2
            pathType: Prefix # 匹配前缀
            backend:
              service:
                name: app2-svc # 指定服务名称
                port:
                  name: app2-port # 指定服务端口名称
            annotations:
              description: "This rule routes traffic to app2." 

在上述示例中，我们定义了一个名为 my-ingress 的 Ingress 对象，使用了 networking.k8s.io/v1 的 API 版本。

使用了 nginx.ingress.kubernetes.io/rewrite-target 注释，将 URL 重写为 /。
如果有一个请求 example.com/app1/some-path，它将被重写为 example.com/，然后将转发到名为 app1-svc 的后端服务。

在 spec 字段中，我们定义了一个规则，将流量路由到 example.com 主机名，并根据不同的路径转发流量到不同的服务端点。

---

3.如何通过命令行在 Kubernetes 中创建一个 Pod？

使用 kubectl run 命令可以在 Kubernetes 中创建一个 Pod。例如：

kubectl run mypod --image=myimage --replicas=1 

将创建一个名为 “mypod” 的 Pod，使用镜像 “myimage”，并指定副本数为 1。

---

4.StatefulSet 和 Deployment 有何区别？你会在什么情况下选择使用 StatefulSet？

StatefulSet 与 Deployment 在应用程序部署和管理方面有所不同。StatefulSet 为有状态应用程序提供唯一标识和稳定网络标识符，并支持有序部署和缩放。通常在需要持久化存储、有状态服务（如数据库）和有序实例启动顺序的情况下选择使用 StatefulSet。

---

5.Kubernetes 的 Rolling Update 策略是什么？如何执行滚动更新？

Rolling Update 是一种逐步更新应用程序的策略，不会中断服务。通过逐步替换旧的 Pod 实例来实现更新。可以通过更新 Deployment 对象的版本号或修改其它可控制滚动更新的参数来执行滚动更新。

---

6.如何在 Kubernetes 中进行水平扩展（Horizontal Pod Autoscaling）？

可以通过创建 HorizontalPodAutoscaler（HPA）资源对象来在 Kubernetes 中实现水平扩展。HPA 根据 CPU 利用率、内存利用率等指标自动调整 Pod 的数量，以实现负载均衡和资源的动态分配。

---

7.什么是 Kubernetes 中的节点（Node）？

节点是 Kubernetes 集群中的工作节点，它是部署容器和运行 Pod 的物理或虚拟机器。每个节点都有一个 kubelet 进程与主控节点（Master）通信，并管理其上的容器和 Pod。

---

8.解释一下 Kubernetes 中的服务发现是什么，以及如何实现服务发现？

服务发现是指能够自动识别和定位集群中正在运行的服务的能力。在 Kubernetes 中，可以使用 Service 对象来实现服务发现。Service 提供了一个虚拟 IP 和 DNS 记录，用于标识一组提供相同服务的 Pod。

Kubernetes 中的服务发现是指自动发现和识别集群中运行的服务的能力。它通过使用 Kubernetes 的内置机制来管理服务的网络标识和访问方式，使得其他应用程序或服务可以轻松地与目标服务进行通信。

服务发现的主要组成部分是 Kubernetes 的 Service 对象。

Service 对象是一种抽象，它为后端 Pod 集合提供了一个稳定的网络终结点，并将它们与一个唯一的 DNS 名称关联起来。

这样，其他应用程序或服务只需通过 DNS 名称即可在整个集群中访问服务，而无需直接关注特定的 Pod IP 地址和端口号。

在 YAML 文件中，您可以使用以下注释来提供详细说明：

apiVersion: v1
kind: Service
metadata:
  name: my-service # 定义服务名称
  labels:
    app: my-app # 定义标签以标识服务
spec:
  selector:
    app: my-app # 选择与该标签匹配的 Pod
  ports:
    - protocol: TCP
      port: 8080
      targetPort: 80 # 将请求转发到 Pod 的端口 80
  type: ClusterIP # 指定服务类型为 ClusterIP

创建了一个名为 my-service 的 Service 对象。使用 metadata 字段来定义服务的名称和标签，其中 app: my-app 是标签的示例。

在 spec 字段中，我们使用 selector 字段指定选择器，它将匹配与指定标签相匹配的 Pod。

这样，Service 将自动识别并路由流量到与该标签匹配的 Pod。

在 ports 字段中，定义了服务暴露的端口号和协议，并使用 targetPort 将请求转发到 Pod 的端口 80。

这意味着任何访问 my-service 的请求都将被转发到标有 app: my-app 标签的 Pod 上的端口 80。

最后，在 type 字段中，我们将服务类型设置为 ClusterIP。这种类型的 Service 只在集群内部可访问，对外部网络不可见。

Kubernetes（k8s）中有以下几种常见的服务类型：

ClusterIP（默认类型）：这是最常见的服务类型，它为集群内部的其他服务提供了一个稳定的虚拟 IP 地址。对于集群外部的请求来说，ClusterIP 类型的服务是不可访问的。

NodePort：NodePort 类型在 ClusterIP 的基础上暴露了一个端口，供外部客户端直接访问服务。该类型会在集群中每个节点上监听一个固定的端口，并自动转发流量到 Service。这样，可以使用节点的 IP 地址和 NodePort 访问服务。

LoadBalancer：LoadBalancer 类型通过云提供商的负载均衡器，将外部流量动态分配到后端服务。该类型需要云提供商支持，并自动创建一个外部负载均衡器来公开服务。通过负载均衡器的 IP 地址，可以从外部网络访问服务。

ExternalName：ExternalName 类型允许您将 Service 映射到集群外部的 DNS 名称。它没有集群内部的代理 IP，而是返回一个 CNAME 记录，指向外部名称。

此外，还有一些罕见或特殊用途的服务类型：

Headless：Headless 类型允许 Pods 直接通过 DNS 进行相互发现，而不会有负载均衡或代理。它没有 ClusterIP，而是返回一个包含所有后端 Pod IP 地址的 DNS 记录列表。

ExternalTrafficPolicy：可用于任何服务类型，用于指定流量从集群外部进入时的处理策略。可以选择 “Cluster” 或 “Local”，决定流量是否仅路由到就近的节点上的 Pod。

Headless

Headless Service 是指在 Kubernetes 中，一种没有 Cluster IP 的 Service 类型。

相反，它返回一个包含所有后端 Pod IP 地址的 DNS 记录列表，从而允许其他服务或应用程序直接与后端 Pod 通信，没有负载均衡或代理的干扰。

它通常用于需要对每个 Pod 进行直接访问的场景，如数据库或分布式系统。

以下是 Headless Service 的示例 YAML 文件及注释，以便更好地理解如何配置：

apiVersion: v1
kind: Service
metadata:
  name: my-headless-service # 定义 Headless Service 名称
  labels:
    app: my-app # 定义 Service 所属的标签
spec:
  selector:
    app: my-app # 指定后端 Pod 的选择器
  clusterIP: None # 将 clusterIP 设置为 None，以指定 Headless Service 类型 
  ports:
    - name: http
      protocol: TCP
      port: 80
      targetPort: 9376 # 指定将流量转发到 Pod 内部的端口

创建了一个名为 my-headless-service 的 Headless Service 对象。我们使用 metadata 字段来定义服务的名称和标签，其中 app: my-app 是标签的示例。

在 spec 字段中，我们使用 selector 字段指定选择器，它将匹配与指定标签相匹配的 Pod。

这样，Service 将自动识别并路由流量到与该标签匹配的 Pod。

在 clusterIP 字段中，我们将 clusterIP 设置为 None，以指定这是一个 Headless Service 类型。
这意味着无法使用稳定的 IP 地址访问服务，而是通过 DNS 记录直接访问每个后端 Pod。

在 ports 字段中，定义了服务暴露的端口号和协议，并使用 targetPort 将请求转发到 Pod 的端口 9376。

这意味着任何对于 my-headless-service 的请求都会被转发到标有 app: my-app 标签的 Pod 上的端口 9376。

---

9.什么是 Kubernetes 中的水平和垂直扩展？

水平扩展（Horizontal Scaling）是指通过增加或减少 Pod 的数量来调整集群的容量以满足负载需求。垂直扩展（Vertical Scaling）是指通过增加或减少单个 Pod 的资源配额（如 CPU、内存）来调整集群的容量。

---

10.Kubernetes 的命名空间（Namespace）有什么作用？可以创建多少个命名空间？

命名空间用于在集群中隔离和划分资源，以便更好地管理和控制资源的访问。Kubernetes 允许创建多个命名空间，默认情况下有一些系统预定义的命名空间（如 default、kube-system 等），用户也可以根据需要创建自己的命名空间。

---

11.如何在 Kubernetes 中进行升级（Upgrade）集群版本？

在 Kubernetes 中，可以通过 kubeadm 工具对集群进行升级。具体的步骤和流程会因为不同的 Kubernetes 版本而有所不同，可以根据官方文档提供的指引进行操作。

---

12.Kubernetes 中的 ConfigMap 和 Secret 有何区别？如何使用它们？

ConfigMap 用于存储非敏感的配置数据，如环境变量、配置文件等。Secret 则用于存储敏感数据，如密码、凭证、密钥等。可以通过创建 ConfigMap 和 Secret 对象，并将它们挂载到 Pod 中来使用它们。

---

13.什么是 PV 和 PVC？它们在 Kubernetes 中的作用是什么？

PV（PersistentVolume）是一种与具体存储技术无关的存储资源，PVC（PersistentVolumeClaim）是一个声明，用于向 Kubernetes 请求特定容量和访问模式的 PV。PV 和 PVC 共同组成了 Kubernetes 中的存储卷管理机制，用于持久化存储数据。

在Kubernetes中，PV（Persistent Volume）是对底层网络共享存储的抽象，将共享存储定义为一种“资源”。PVC（Persistent Volume Claim）则是用户对存储资源的一个“申请”。

关于PV和PVC，以下是一些可能的面试题及其详细解释：

什么是PV和PVC，它们在Kubernetes中的角色是什么？

PV是Kubernetes中的存储资源，它是底层的网络共享存储的抽象，可以将共享存储视为一种“资源”。
PVC是用户对存储资源的一个“申请”，它描述了用户需要的存储资源的特性，如容量、访问模式等。

---

PV的生命周期是怎样的？

PV的生命周期可能包括以下四个阶段：

• Available（可用状态，还未与某个PVC绑定）、
• Bound（已与某个PVC绑定）、
• Released（绑定的PVC已经删除，资源已释放，但没有被集群回收）、
• Failed（自动资源回收失败）。

---

PV和PVC的关系是什么？

PV和PVC的关系是动态的。
PVC可以与一个或多个PV关联，以申请特定的存储资源。

当一个PV被一个PVC申请后，它们就处于Bound状态，表示该PV已经被分配给相应的PVC使用。
当PVC被删除或不再需要时，相应的PV将被释放，进入Released状态，等待被集群回收。

---

Kubernetes支持哪些存储供应模式？

Kubernetes支持两种资源的存储供应模式：静态模式（Static）和动态模式（Dynamic）。

在静态模式中，集群管理员手动创建许多PV，并在定义PV时将后端存储的特性进行设置。
这种模式下，管理员需要预先知道存储需求，并手动创建相应的PV。

在动态模式中，集群管理员无须手动创建PV，而是通过StorageClass的设置对后端存储进行描述，标记为某种类型。
当一个PVC被创建并指定了StorageClass时，系统会自动完成PV的创建及与PVC的绑定。
这种模式更加灵活，可以更好地管理存储资源。

---

如何使用PV和PVC进行存储管理？

在Kubernetes中，使用PV和PVC进行存储管理主要包括以下步骤：

• 定义一个PV，并指定后端存储的特性。
• 创建一个PVC，并指定所需的存储资源的特性。
• 当PVC被创建后，系统会自动为其寻找可用的PV并进行绑定。
• 当不再需要PVC时，可以删除它，系统会自动将相应的PV释放并回收。

---

PV和PVC的优点和缺点是什么？

PV和PVC的优点：

• 可以方便地对存储资源进行抽象、申请和管理。
• 支持动态和静态两种存储供应模式。
• 支持存储资源的自动回收和再利用。

PV和PVC的缺点：

• 需要额外的存储资源管理开销。
• 需要预先定义或手动创建PV，可能会增加管理员的工作负担。

---

pv和pvc使用

apiVersion: v1
kind: PersistentVolume
metadata:
  name: example-pv        # PV 的名称
spec:
  storageClassName: slow  # 存储类的名称，用于将 PV 绑定到匹配的 PVC 上
  capacity:
    storage: 10Gi        # PV 的存储容量
  accessModes:
    - ReadWriteOnce       # 访问模式，表示可以由一个 Pod 以读写模式挂载
  persistentVolumeReclaimPolicy: Retain  # 回收策略，表示删除后保留 PV 中的数据
  nfs:
    path: /nfs/path       # NFS 服务器上的路径
    server: nfs.example.com # NFS 服务器的地址

---

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: example-pvc        # PVC 的名称
spec:
  storageClassName: slow   # 存储类的名称，要与 PV 上的存储类匹配
  accessModes:
    - ReadWriteOnce        # 访问模式，必须与 PV 上的访问模式匹配
  resources:
    requests:
      storage: 5Gi         # 请求的存储资源大小

---

apiVersion: v1
kind: Pod
metadata:
  name: example-pod        # Pod 的名称
spec:
  containers:
    - name: my-container
      image: my-image
      volumeMounts:
        - name: my-volume   # 指定需要挂载的卷名称
          mountPath: /data   # 挂载到容器中的路径
  volumes:
    - name: my-volume      # 定义需要挂载的卷
      persistentVolumeClaim:
        claimName: example-pvc # 指定 PVC 的名称，用于查找匹配的 PV 进行挂载

动态模式存储是指在 Kubernetes 中使用动态配置的存储类（StorageClass）来实现 PV 和 PVC 的自动创建和绑定。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: example-pvc        # PVC 的名称
spec:
  storageClassName: slow   # 存储类的名称，用于动态创建和绑定 PV
  accessModes:
    - ReadWriteOnce        # 访问模式，可以由一个 Pod 以读写模式挂载
  resources:
    requests:
      storage: 5Gi         # 请求的存储资源大小

在上面的示例中，我们只需要创建一个 PVC，并指定所需的存储资源大小、访问模式和存储类名称。Kubernetes 将根据存储类的定义自动创建一个匹配需求的 PV，并将其与该 PVC 进行绑定。

要启用动态模式存储，需要完成以下步骤：

• 首先，确保 Kubernetes 集群已经配置了动态存储类。这可能涉及到与存储提供商集成，例如安装并启用 CSI 驱动程序。

• 创建存储类的定义。存储类定义中指定了如何动态创建和配置 PV。以下是一个存储类定义的示例：

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: slow              # 存储类的名称
provisioner: example.com/nfs  # 存储提供商或 CSI 驱动程序的名称
parameters:
  type: "slow"            # 存储类型参数

在这个示例中，存储提供商是 example.com/nfs，而 type 参数指定了存储的类型为 “slow”。

创建 PVC。在 PVC 的定义中，指定存储类的名称，并描述所需的存储资源和访问模式。

Kubernetes 将根据 PVC 的定义和存储类的配置，自动创建一个匹配需求的 PV，并将其与该 PVC 进行绑定。

如果没有合适的可用 PV， Kubernetes 可以自动创建新的 PV。

动态模式存储简化了 PV 和 PVC 的管理，使得开发人员可以专注于使用存储资源而无需手动创建和维护 PV。

---

14.如何设置 Kubernetes 中的资源配额（Resource Quota）？

可以使用 ResourceQuota 对象来设置 Kubernetes 中的资源配额。ResourceQuota 可以限制命名空间或用户对资源（如 CPU、内存）的使用量，并确保不会超过指定的配额。

---

要将创建的 ResourceQuota 对象应用于特定的命名空间，可以使用以下步骤：

1. 创建 ResourceQuota 文件

首先，创建一个 YAML 文件来定义 ResourceQuota 对象，指定资源配额的限制。例如，创建一个名为 my-quota.yaml 的文件。

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

2. 应用 ResourceQuota

使用 kubectl apply 命令将 ResourceQuota 对象应用到特定的命名空间。

kubectl apply -f my-quota.yaml --namespace=my-namespace

3. 验证 ResourceQuota 是否应用成功

kubectl get resourcequota --namespace=my-namespace

如果成功应用，将显示与 ResourceQuota 相关的信息，包括 ResourceQuota 的名称、指定的限制以及用量情况。

请注意，您也可以在命名空间创建时直接指定 ResourceQuota 对象，而不是在后续步骤中手动应用。通过在创建命名空间时添加 --resource-quota=my-quota 参数，将会自动将指定的 ResourceQuota 应用于新创建的命名空间。

kubectl create namespace my-namespace --resource-quota=my-quota

这样，创建的命名空间将自动与 ResourceQuota 关联。

通过将 ResourceQuota 应用于特定的命名空间
可以确保该命名空间内的资源使用量不会超过指定的配额限制。

---

15.Kubernetes 中的 Init 容器是什么？请提供一个使用案例。

Init 容器是在主容器启动之前运行的短暂容器，用于完成初始化任务或设置共享数据。

例如，在某些应用程序中可以使用 Init 容器进行数据库初始化或加载配置文件等操作，以便主容器在运行时获得正确的环境。

Init 容器可以用于初始化 Pod 的环境、准备存储卷、执行特定的任务或启动依赖项。只有当 Init 容器成功完成并退出后，才会继续启动其他容器。

apiVersion: v1
kind: Pod
metadata:
  # 定义 Pod 元数据
  name: my-pod
spec:
  # 定义 Pod 规范
  containers:
    - name: main-container # 主容器
      image: nginx:latest # 使用 Nginx 最新版本镜像
      ports:
        - containerPort: 80 # 暴露80端口
  initContainers:
    - name: init-container # 初始化容器
      image: busybox:latest # 使用 Busybox 最新版本镜像
      command: ['sh', '-c', 'echo "Initializing..."'] # 执行初始化命令
      annotations:
        description: "This is an example init container." # 这是一个示例 Init 容器，用于初始化 Pod 的环境

---