[面试] k8s面试题 2-Toy模板网

这篇具有很好参考价值的文章主要介绍了[面试] 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，您需要满足以下条件：

集群中运行一个支持 Ingress 控制器的 Kubernetes 集群。
在 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 对象应用于特定的命名空间，可以使用以下步骤：

创建 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

应用 ResourceQuota

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

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

验证 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 的环境