Linux运维工程师面试题（9）
祝各位小伙伴们早日找到自己心仪的工作。
持续学习才不会被淘汰。
地球不爆炸，我们不放假。
机会总是留给有有准备的人的。
加油，打工人！
1 pod 的生命周期
第一阶段：
- Pending：正在创建 Pod 但是 Pod 中的容器还没有全部被创建完成，处于此状态的 Pod 应该检查 Pod 依赖的存储是否有权限挂载、镜像是否可以下载、调度是否正常等。
- Failed：Pod 中有容器启动失败而导致 pod 工作异常。
- Unknown：由于某种原因无法获得 pod 的当前状态，通常是由于与 pod 所在的 node 节点通信错误。
- Succeeded：Pod 中的所有容器都被成功终止即 pod 里所有的 containers 均已 terminated。
第二阶段：
- Unschedulable：Pod不能被调度，kube-scheduler 没有匹配到合适的node节点
- CPU资源不够，内存资源不够
- 打 labels 标签
- PodScheduled：pod 正处于调度中，在 kube-scheduler 刚开始调度的时候，还没有将 pod 分配到指定node，在筛选出合适的节点后就会更新 etcd 数据，将 pod 分配到指定的 node
- Initialized：所有 pod 中的初始化容器已经完成了
- ImagePullBackOff：Pod 所在的 node 节点下载镜像失败
- node 节点无法下载镜像
- 网络问题
- 权限问题
- 镜像地址或者名称写错
- Running：Pod 内部的容器已经被创建并且启动
- Ready：表示 pod 中的容器已经可以提供访问服务
2 探针类型
- livenessProbe：存活探针，检测容器是否正在运行，如果存活探测失败，则 kubelet 会杀死容器，并且容器将受到其重启策略的影响，如果容器不提供存活探针，则默认状态为 Success，livenessProbe 用户控制是否重启 pod。
- readinessProbe：就绪探针，如果就绪探测失败，端点控制器将从与 Pod 匹配的所有 Service 的端点中删除该 Pod 的 IP 地址，初始延迟之前的就绪状态默认为 Failure，如果容器不提供就绪探针，则默认状态为 Success，readinessProbe 用于控制 pod 是否添加至 service。
livenessProbe 和 readinessProbe 的对比
配置参数一样
livenessProbe：连续探测失败会重启、重建 pod，readinessProbe 不会执行重启或者重建Pod操作
livenessProbe：连续检测指定次数失败后会将容器置于 (Crash Loop BackOff) 切不可用，readinessProbe 不会
readinessProbe：连续探测失败会从 service 的 endpointd 中删除该 Pod，livenessProbe 不具备此功能，但是会将容器挂起 livenessProbe
livenessProbe 用户控制是否重启 pod，readinessProbe 用于控制 pod 是否添加至 service
3 探针方式
- ExecAction： 在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功。
- TCPSocketAction： 对容器的 IP 地址上的指定端口执行 TCP 检查。如果端口打开，则诊断被认为是成功的。
- HTTPGetAction： 对容器的 IP 地址上指定端口和路径执行 HTTP Get 请求。如果响应的状态码大于等于 200 且小于 400，则诊断被认为是成功的。
4 探针结果
- Success （成功）：容器通过了诊断。
- Failure （失败）：容器未通过诊断。
- Unknown （未知）：诊断失败，因此不会采取任何行动。
5 Pod 重启策略
restartPolicy：
- Always：当容器异常时，k8s 自动重启该容器，ReplicationController/Replicaset/Deployment。
- OnFailure：当容器失败时 (容器停止运行且退出码不为0)，k8s 自动重启该容器。
- Never：不论容器运行状态如何都不会重启该容器，Job 或 CronJob。
6 镜像获取策略
imagePullPolicy:
- Always：每次启动Pod时都要从指定的仓库下载镜像。
- IfNotPresent：仅本地镜像缺失时才从目标仓库下载镜像。
- Never：禁止从仓库下载镜像，仅使用本地镜像。
对于标签为 latest 的镜像文件，其默认的镜像获取策略为Always；
其他标签的镜像，默认策略则为IfNotPresent。
7 k8s 的服务类型
ClusterIP：通过集群的内部 IP 暴露服务，选择该值时服务只能够在集群内部访问。 这也是你没有为服务显式指定type时使用的默认值。 你可以使用 Ingress 或者 Gateway API 向公众暴露服务。NodePort：通过每个节点上的 IP 和静态端口（NodePort）暴露服务。 为了让节点端口可用，Kubernetes 设置了集群 IP 地址，这等同于你请求type: ClusterIP的服务。LoadBalancer：使用云提供商的负载均衡器向外部暴露服务。 外部负载均衡器可以将流量路由到自动创建的NodePort服务和ClusterIP服务上。ExternalName：通过返回CNAME记录和对应值，可以将服务映射到externalName字段的内容（例如，foo.bar.example.com）。 无需创建任何类型代理。
8 k8s中 service 和 ingress 的区别
service 只能通过四层负载就是ip+端口的形式来暴露
ingress 可以提供7层的负责对外暴露接口，而且可以调度不同的业务域，不同的url访问路径的业务流量。
9 有状态和无状态服务的区别
http请求无状态，多次请求之间没有依赖关系
有状态就是多次访问之间有关联关系，需要记录多次之间的访问关系
10 k8s 中 service 是做什么的？
主要是做动态的发现后端主机的endpoint并提供负载均衡的一个入口。
关于我
全网可搜《阿贤Linux》
CSDN、知乎、哔哩哔哩、博客园、51CTO、掘金、思否、开源中国、阿里云、腾讯云、华为云、今日头条、百家号、GitHub、个人博客
公众号：阿贤Linux
个人博客：blog.waluna.top
https://blog.waluna.top/
原文链接: Linux运维工程师面试题（9）.