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).