2025年容器运维工程师试题及答案

2025年容器运维工程师试题及答案一、单项选择题（每题2分，共20分）1.以下Kubernetes组件中，负责节点上容器生命周期管理的是？A.kube-apiserverB.kube-controller-managerC.kube-schedulerD.kubelet答案：D解析：kubelet是节点上的代理，负责Pod的创建、启动、监控、重启及销毁，直接管理容器运行时（如Containerd）。2.某Pod配置了`resources.requests.cpu:1`和`resources.limits.cpu:2`，当节点CPU使用率达到100%时，该Pod的CPU实际使用量会被限制为？A.1核B.2核C.节点剩余可用核数D.根据QoS等级动态调整答案：D解析：Pod的QoS等级由requests和limits配置决定。若requests与limits相等为Guaranteed，仅requests为Burstable，无requests为BestEffort。当资源竞争时，Guaranteed优先保留，Burstable可能被限制，BestEffort可能被回收。本题中requests（1核）<limits（2核），属于Burstable，实际使用量会根据节点资源情况动态调整，但不会超过limits。3.关于Kubernetes网络策略（NetworkPolicy），以下说法错误的是？A.需要网络插件（如Calico）支持才能生效B.默认所有Pod间流量互通C.可通过`podSelector`和`namespaceSelector`定义规则D.支持基于TCP/UDP端口的入站（ingress）和出站（egress）控制答案：B解析：默认情况下（无NetworkPolicy时），Kubernetes集群内Pod间流量是允许的；但如果网络插件（如Calico）启用了默认拒绝策略（DefaultDeny），则需要显式允许流量。题目未说明插件配置，严格来说B选项描述不准确。4.某StatefulSet的`replicas:3`，`updateStrategy.type:RollingUpdate`，`partition:1`。执行镜像更新后，会更新的Pod是？A.pod-0、pod-1、pod-2B.pod-1、pod-2C.pod-2D.无Pod更新答案：B解析：RollingUpdate策略下，partition参数指定更新的起始索引（从0开始）。当partition=1时，索引≥1的Pod（pod-1、pod-2）会被更新，索引<1的Pod（pod-0）保持旧版本。5.以下哪项不是Containerd的核心组件？A.containerd-shimB.runcC.CRI插件D.kube-proxy答案：D解析：kube-proxy是Kubernetes组件，负责服务网络代理；containerd的核心组件包括shim（管理容器生命周期）、runc（OCI运行时）、CRI插件（与kubelet交互）。6.若需要限制命名空间内所有Pod的CPU总和不超过8核，应使用以下哪个资源对象？A.ResourceQuotaB.LimitRangeC.PodDisruptionBudgetD.HorizontalPodAutoscaler答案：A解析：ResourceQuota用于限制命名空间内资源总量（如CPU总和、PVC数量）；LimitRange用于限制单个Pod/容器的requests/limits。7.某应用需要挂载NFS存储，且要求多个Pod可同时读写，应选择以下哪种PVC访问模式？A.ReadWriteOnce（RWO）B.ReadOnlyMany（ROX）C.ReadWriteMany（RWX）D.ReadWriteOncePod（RWOP）答案：C解析：RWX模式允许多个节点上的Pod同时读写，适用于共享存储场景；RWO仅允许单个节点读写，ROX允许多节点只读。8.关于Kubernetes污点（Taint）和容忍（Toleration），以下说法正确的是？A.污点标记在Pod上，容忍标记在节点上B.容忍的`operator`字段默认是`Equal`C.污点`NoSchedule`表示已运行的Pod会被驱逐D.节点故障时，kubelet会自动添加`node.kubernetes.io/not-ready`污点答案：B解析：A错误，污点标记在节点，容忍标记在Pod；C错误，NoSchedule阻止新Pod调度，不驱逐已运行Pod；D错误，节点故障时kubelet会添加`node.kubernetes.io/unreachable`等污点，not-ready通常由健康检查触发。9.升级Kubernetes集群时，正确的操作顺序是？A.升级控制平面→升级kubelet→升级节点→更新kube-proxyB.升级节点→升级kubelet→升级控制平面→更新kube-proxyC.升级控制平面→升级节点（含kubelet）→更新kube-proxyD.升级kube-proxy→升级控制平面→升级节点→升级kubelet答案：C解析：标准升级流程为：先升级控制平面组件（apiserver、scheduler、controller-manager），再逐个升级工作节点（先排水节点，升级kubelet和容器运行时，重启服务），最后更新kube-proxy等组件。10.以下Prometheus指标类型中，适用于统计请求耗时的是？A.Counter（计数器）B.Gauge（仪表盘）C.Histogram（直方图）D.Summary（摘要）答案：C解析：Histogram用于统计数据分布（如请求耗时区间），可计算分位数（如p99）；Summary也可计算分位数但依赖客户端，Histogram由服务端聚合更灵活。二、填空题（每空2分，共20分）1.Kubernetes默认的服务账户（ServiceAccount）名称是__________。答案：default2.查看Pod的事件日志应使用命令：kubectl__________pod<pod-name>。答案：describe3.Containerd的配置文件默认路径是__________。答案：/etc/containerd/config.toml4.StatefulSet的Pod名称格式是__________。答案：<statefulset-name>-<ordinal>（如web-0、web-1）5.若需要让Pod优先调度到带有标签`disk=ssd`的节点，应配置__________字段（属于Pod.spec）。答案：affinity.nodeAffinity.preferredDuringSchedulingIgnoredDuringExecution6.Kubernetes中，用于记录API请求操作的审计日志功能由__________组件处理。答案：kube-apiserver7.配置Ingress时，若使用Nginx控制器，指定后端服务端口的注解是__________。答案：nginx.ingress.kubernetes.io/backend-protocol（或具体端口注解，如默认80/443时无需显式指定）8.某Pod的`restartPolicy`默认值是__________。答案：Always9.监控Kubernetes组件时，kube-scheduler的指标通常暴露在__________端口。答案：10259（https）或10251（http，K8s1.26+废弃）10.实现Pod跨命名空间访问Service的方式是通过__________（填写资源类型）。答案：Service（通过FQDN：<service-name>.<namespace>.svc.cluster.local）三、简答题（每题8分，共40分）1.简述Kubernetes中Pod的生命周期阶段，并说明`Pending`和`ContainerCreating`状态的区别。答案：Pod生命周期阶段包括：Pending（调度中）、ContainerCreating（容器创建中）、Running（运行中）、Succeeded（正常结束）、Failed（失败）、Unknown（状态未知）。Pending状态表示Pod已被APIServer接受，但尚未完成调度（未分配节点）或镜像拉取未开始；ContainerCreating状态表示Pod已调度到节点，kubelet正在与容器运行时交互创建容器（如拉取镜像、配置网络/存储）。2.说明StatefulSet与Deployment的核心区别，列举至少3个适用场景。答案：核心区别：唯一稳定标识：StatefulSet的Pod名称、网络标识（DNS）、存储（PVC）与序号绑定，重启后保持不变；Deployment的Pod无稳定标识。有序性：StatefulSet创建（0→N）、更新（N→0）、删除（N→0）有序；Deployment无固定顺序。存储管理：StatefulSet通过VolumeClaimTemplates自动创建PVC，与Pod绑定；Deployment需手动管理PVC或使用共享存储。适用场景：有状态应用（如数据库MySQL、Redis集群），需要稳定的网络标识和持久化存储。需要按顺序启动/更新的应用（如分布式协调服务ZooKeeper）。需要依赖固定节点拓扑的应用（如分布式存储Ceph的OSD节点）。3.如何排查Kubernetes集群中Pod无法拉取镜像的问题？请列出至少5个排查步骤。答案：排查步骤：（1）检查Pod状态：`kubectlgetpod<pod-name>-owide`，确认是否处于`ImagePullBackOff`或`ErrImagePull`状态。（2）查看事件日志：`kubectldescribepod<pod-name>`，定位具体错误（如镜像不存在、认证失败）。（3）检查镜像名称和标签：确认`spec.containers.image`字段是否正确（是否包含仓库地址、标签是否存在）。（4）验证镜像仓库访问权限：若仓库需要认证，检查Pod是否挂载了正确的Secret（通过`imagePullSecrets`字段）。手动在节点上执行`crictlpull<image>`（或`dockerpull`），测试是否能拉取。（5）检查节点网络：确保节点能访问镜像仓库（如私有仓库的IP/域名解析是否正常，防火墙规则是否允许出站流量）。（6）查看容器运行时日志：Containerd日志：`journalctl-ucontainerd-n100`CRI插件日志：`kubectllogs<kubelet-pod>-nkube-system-ckubelet`（或`journalctl-ukubelet`）。（7）检查镜像大小与节点存储：若镜像过大，确认节点可用磁盘空间是否足够（`df-h`）。4.说明KubernetesHorizontalPodAutoscaler（HPA）的工作原理，并列举其支持的指标类型。答案：工作原理：HPA控制器通过聚合API（如metrics.k8s.io、custom.metrics.k8s.io）获取Pod的资源指标（如CPU、内存）或自定义指标（如请求数），与目标值比较后调整Deployment/StatefulSet的副本数。调整策略基于当前指标与目标的比值，结合冷却时间（默认300秒）避免频繁缩放。支持的指标类型：资源指标（ResourceMetrics）：CPU、内存（来自metrics-server）。Pods指标（PodsMetrics）：所有Pod的指标平均值（如自定义的QPS）。对象指标（ObjectMetrics）：单个对象（如Service）的指标（如连接数）。外部指标（ExternalMetrics）：集群外的指标（如云存储的IOPS）。按每个Pod的指标（Per-PodMetrics）：K8s1.23+支持，基于单个Pod的指标值。5.对比Calico与Cilium的网络模型，说明Cilium在服务网格场景中的优势。答案：网络模型对比：Calico：基于BGP或IPIP/VXLAN的三层网络，通过iptables/IPsets实现网络策略。Cilium：基于eBPF技术，直接在Linux内核层面实现二到七层的流量处理，支持更细粒度的网络策略（如HTTP头过滤）。Cilium在服务网格中的优势：（1）高性能：eBPF绕过传统内核网络栈，减少转发延迟，适合高吞吐量场景。（2）七层流量控制：支持基于HTTP、gRPC、DNS等协议的策略（如限制特定URL的访问）。（3）可观测性增强：通过eBPF采集更详细的流量元数据（如请求路径、响应状态码），无需Sidecar代理即可实现服务网格的追踪功能。（4）与Kubernetes集成更紧密：支持EndpointSlice、GatewayAPI等新特性，简化服务间通信配置。四、实操题（每题15分，共30分）1.请写出在Kubernetes集群中部署一个高可用的Redis主从集群（1主2从）的完整步骤，要求：使用StatefulSet管理Pod主节点持久化存储（5Gi，使用`nfs-storage`StorageClass）从节点同步主节点数据（通过`redis-serverslaveof<master-ip><port>`启动参数）服务暴露：主节点通过ClusterIP服务（端口6379），从节点通过Headless服务（便于DNS发现）答案：步骤1：创建StorageClass（若不存在）```yamlnfs-storageclass.yamlapiVersion:storage.k8s.io/v1kind:StorageClassmetadata:name:nfs-storageprovisioner:nfs-clientreclaimPolicy:RetainvolumeBindingMode:Immediate````kubectlapply-fnfs-storageclass.yaml`步骤2：创建StatefulSet```yamlredis-statefulset.yamlapiVersion:apps/v1kind:StatefulSetmetadata:name:redisspec:serviceName:redis-headlessreplicas:3selector:matchLabels:app:redistemplate:metadata:labels:app:redisspec:containers:name:redisimage:redis:7.0ports:containerPort:6379name:redis-portcommand:"redis-server""port""6379""replicaof""$(MASTER_HOST)""6379"env:name:MASTER_HOSTvalue:"redis-0.redis-headless.default.svc.cluster.local"主节点DNS名称（序号0）volumeMounts:name:datamountPath:/datavolumeClaimTemplates:metadata:name:dataspec:accessModes:["ReadWriteOnce"]storageClassName:"nfs-storage"resources:requests:storage:5Gi```步骤3：创建Headless服务（用于从节点发现主节点）```yamlredis-headless-svc.yamlapiVersion:v1kind:Servicemetadata:name:redis-headlessspec:clusterIP:Noneselector:app:redisports:port:6379targetPort:6379```步骤4：创建主节点ClusterIP服务（仅暴露主节点）```yamlredis-master-svc.yamlapiVersion:v1kind:Servicemetadata:name:redis-masterspec:type:ClusterIPselector:app:redisstatefulset.kubernetes.io/pod-name:redis-0仅选择主节点（序号0）ports:port:6379targetPort:6379```步骤5：应用配置并验证```bashkubectlapply-fredis-headless-svc.yamlkubectlapply-fredis-master-svc.yamlkubectlapply-fredis-statefulset.yaml验证Pod状态kubectlgetpods-lapp=redis验证存储kubectlgetpvc-lapp=redis登录主节点验证从节点连接kubectlexec-itredis-0redis-cliinforeplication应显示"role:master"，"connected_slaves:2"```2.某Kubernetes集群出现节点CPU使用率持续90%以上的问题，请设计排查方案，要求包含工具使用、数据采集和可能的根因分析。答案：排查方案：（1）初步定位节点：使用`kubectltopnodes`查看各节点CPU使用率，确定高负载节点（如node-1）。（2）采集节点层面数据：登录节点执行`top`或`htop`，查看进程CPU占用（关注%CPU列）。使用`pidstat-u15`（每秒采样，共5次）定位持续高CPU的进程PID。检查容器运行时：`crictlstats`或`dockerstats`，查看容器级CPU使用（对应KubernetesPod：`kubectlgetpod-owide`确认PID对应的容器）。（3）分析Kubernetes资源分配：查看节点上Pod的资源请求与限制：`kubectldescribenodenode-1|grep-A20"Allocatedresources"`，确认是否超卖（requests总和>节点CPU容量）。检查Pod的QoS等级：`kubectlgetpod<pod-name>-ojsonpath='{.status.qosClass}'`，BestEffortPod可能被优先限制。（4）深入进程分析：对高CPU进程（如PID=12345），使用`strace-p12345`查看系统调用（如频繁IO或网络操作）。若为Java进程，使用`jstack12345`生成线程栈，结合`javacore`或`async-profiler`分析热点方法。若为Go进程，使用`pprof`工具采集CPUprofile（`http://<pod-ip>:6060/debug/pprof/profile`）。（5）检查调度与资源竞争：查看kube-scheduler日志（`journalctl-ukube-scheduler`），确认是否有异常调度导致节点负载不均。检查是否有容器设置了过高的`limits.cpu`但实际使用低，导致节点预留资源浪费（可通过VPA自动调整）。（6）可能的根因：应用程序代码缺陷（如死循环、未优化的算法）。容器资源限制不合理（如limits过高导致节点超卖）。节点硬件问题（如CPU故障、散热不良）。外部流量突增（如HPA未及时扩容，导致单节点负载过高）。系统进程异常（如kubelet、containerd、日志收集器fluentd等组件内存泄漏或CPU泄漏）。（7）验证与修复：若为应用问题，优化代码或调整HPA策略（如降低`targetCPUUtilizationPercentage`）。若为资源分配问题，调整Pod的requests/limits或使用VPA（VerticalPodAutoscaler）。若为节点硬件问题，标记节点为不可调度（`kubectlcordonnode-1`），迁移Pod后修复硬件。五、综合分析题（20分）某电商公司容器化平台（Kubernetes1.28集群）需要满足以下需求：（1）核心交易应用需要99.99%可用性，故障恢复时间（RTO）≤5分钟；（2）大促期间（如双11）流量可能激增10倍，需自动扩缩容；（3）敏感数据（如用户手机号）需加密存储，禁止明文出现在日志或配置中；（4）所有服务间通信需通过TLS加密，且支持服务身份认证。请设计技术方案，涵盖高可用架构、弹性伸缩、安全加固、网络加密四个方面，要求给出具体实现方式。答案：一、高可用架构设计（RTO≤5分钟）1.控制平面高可用：部署3节点控制平面（apiserver、scheduler、controller-manager），使用etcd集群（3节点，跨AZ部署）。控制平面通过负载均衡器（如HAProxy）对外提供服务，避免单点故障。2.工作节点高可用：节点分布在至少2个可用区（AZ），每个AZ部署≥3个节点。为核心应用配置PodDisruptionBudget（PDB），限制自愿中断时的最小可用副本数（如`minAvailable:2`）。启用Pod反亲和性（`podAntiAffinity`），确保同应用Pod分布在不同节点/AZ：```yamlaffinity:podAntiAffinity:preferredDuringSchedulingIgnoredDuringExecution:weight:100podAffinityTerm:labelSelector:matchExpressions:key:appoperator:Invalues:[core-trade]topologyKey:kubernetes.io/hostname```3.快速故障恢复：启用kubelet的`node-status-update-frequency`（默认10秒）和`node-monitor-grace-period`（默认40秒），缩短节点故障检测时间。使用Velero进行集群备份（每天全量+每小时增量），故障时通过`velerorestore`快速恢复资源（RTO≤5分钟）。二、弹性伸缩方案（大促流量应对）1.水平伸缩（HPA）：为核心应用Deployment配置HPA，基于CPU（80%）、内存（70%）和自定义指标（如QPS）：```yamlapiVersion:autoscaling/v2kind:HorizontalPodAutoscalermetadata:name:trade-hpaspec:scaleTargetRef:apiVersion:apps/v1kind:Deploymentname:trade-appminReplicas:5maxReplicas:50metrics:type:Resourceresource:name:cputarget:type:UtilizationaverageUtilization:80type:Podspods:metric:name:http_requests_per_secondtarget:type:AverageValueaverageValue:1000```2.垂直伸缩（VPA）：部署VerticalPodAutoscaler，自动调整Pod的requests/limits，避免资源浪费或不足：```yamlapiVersion:autoscaling.k8s.io/v1kind:VerticalPodAutoscalermetadata:name:trade-vpaspec:targetRef:apiVersion:apps/v1kind:Deploymentname:trade-appupdatePolicy:updateMode:"Auto"```3.集群自动扩缩（CA）：集成云厂商的ClusterAutoscaler，当节点资源不足时自动创建新节点（基于HPA的副本需求），大促后自动缩容空闲节点。三、敏感数据安全