共计 2560 个字符，预计需要花费 7 分钟才能阅读完成。
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）.