k8s面试题

1、就绪探针和存活探针

　　kubelet定期执行探针来诊断容器的健康状态

　　1.1、livenessProbe探针 和 ReadinessProbe探针 的区别

　　　　livenessProbe探针：

　　　　　　可根据自定义规则探测pod是否健康，不健康则按照设置的重启策略进行重启，如果此容器不包含此探针，则默认返回的值永远是成功的

　　　　ReadinessProbe探针：

　　　　　　可根据自定义规则判断pod是否健康，不健康，控制器会将pod从service的endipoint列表中去除，不再将任何请求调度到此pod上，知道下次探测成功

区别：

　　一个是基于策略重启容器，一个是将流量去除

参数说明：

• initialDelaySeconds：初始第一次探测间隔，用于应用启动的时间，防止应用还没启动而健康检查失败
• periodSeconds：检查间隔，多久执行probe检查，默认为10s；
• timeoutSeconds：检查超时时长，探测应用timeout后为失败；
• successThreshold：成功探测阈值，表示探测多少次为健康正常，默认探测1次。

2、service资源对象的作用

　　service提供了一个统一的服务访问入口以及服务代理和发现机制

 

3、组件说明和功能

　　3.1、master控制组件

　　　　kubectl：客户端命令行工具，作为整个k8s集群的操作入口

　　　　api-server：作为k8s系统的入口，它提供了认证、授权、访问控制、api注册、发现等机制

　　　　controller-manager：负责管理控制器的进程，维护集群的状态，比如故障检测，自动扩展，滚动更新

　　　　　　节点控制器(node controller)：负责在节点出现故障时进行通讯和响应

　　　　　　任务控制器(job controller)：检测代表一次性任务的job对象，然后创建pods来运行这些任务直至完成

　　　　　　端口分片控制器(endpointslice controller)：填充端口分片(endpointslice)对象(以提供services和pod之间的链接)

　　　　　　服务账号控制器(serviceaccount controller)：为新的命名空间创建默认的服务账号

　　　　scheduler：负责资源调度，按照预订的调度策略将pod调度到对应的node节点上

　　　　etcd：分布式键值存储数据库，保存了整个集群的状态

 

　　3.2、node组件

　　　　kubelet：在集群每个节点上运行，保证容器都运行在pod中

　　　　kube-proxy：在集群每个节点上运行，网络代理，实现k8s services概念的一部分，它维护节点上的一些网络规则，这些网络规则会允许从集群内部活外部的网络会话与pod进行网络通信，如果操作系统提供了可用的数据包过滤层，则kube-proxy会通过它来实现网络规划，否则，kube-proxy仅做流量转发

　　　　container runtime：负责运行容器的组件

 

4、pod的创建过程中的组件联动

　　4.1、用户在控制台执行kubectl命令发起请求

　　4.2、apiserver收到指令后，验证kubeconfig，认证通过后将yaml中的pod信息存到etcd中

　　4.3、controller-manager监听apiserver的watch接口的pod信息，执行该资源所依赖的拓扑结构整合，

　　　　整合后对应的信息返回给apiserver，apiserver将pod信息存储到etcd存储中

　　4.4、kube-scheduler监听apiserver的watch接口更新到pod可以被调度，通过算法给pod分配节点，

　　　　然后将pod和对应节点绑定的信息返回给apiserver，apiserver将信息写入etcd

　　4.5、kubelet从apiserver获取需要创建的pod信息，调用cni容器网络接口(Container Network Interface)给pod创建pod网络，调用cri接口启动容器(Container Runtime Interface)，调用csi(container storage interface)进行存储卷的挂载

　　4.6、网络、容器、存储创建完成后，pod创建完成，等待就绪探针和存活探针检测完成，pod运行成功

 

5、Replica Set 和 Replication Controller的区别

　　他俩几乎相同，都是确保在任何给定时间运行指定数量的pod副本

　　不同之处在于，复制pod的选择器，rs使用基于集合的选择器，rc使用基于权限的选择器

 

6、DaemonSet资源对象的特性

　　该资源对象会在每一个集群节点上只运行一个pod，这是它和deployment的唯一区别

　　一般使用场景：

　　　　6.1、每个节点的日志收集工作

　　　　6.2、监控每个节点的运行状态

 

7、删除一个pod的流程

　　7.1、执行kubectl delete命令时，带grace-period=30s

　　7.2、apiserver更新pod的宽限期字段，默认有30s，优雅退出，超过30s会被标记有死亡状态，

　　7.3、此时pod状态为terminating，开始关闭pod

　　7.4、如果pod模板中定义了prestop，则会执行这个配置，如果过了宽限期，prestop还在执行，会一次性延迟宽限期2s，如果要延长宽限期要改字段

　　　　同时向容器发送term信息，此时pod信息会从service的endpoints列表中移除

　　7.5、宽限期过期时，pod中所有运行的进行被sigkill杀死

　　也可以直接设置grace-period=0 立即删除

　　

8、ingress介绍

　　ingress公开从集群外部到集群内部服务的http和https路由，流量路由由ingress资源上定义的规则控制

　　ingress流程(原理)如下：

　　客户端 →→ ingress负载均衡器 →→　ingress  →→ 路由规则 →→　service →→ 多个pod →→

　　ingress controller 通常负责通过负载均衡器来实现ingress，尽管它也可以配置边缘路由或其他前端来帮助处理流量

 

　　8.1、ingress解决

　　　　　　域名和服务(service)的对应关系

　　8.2、ingress controller解决

　　　　将ingress的变化生成一段nginx的配置，然后将配置通过api 写到nginx-ingress-controller的pod中的nginx的配置文件中，然后reload，以此达到分配和动态更新的问题

　 　8.3、ingress的组成

　　反向代理负载均衡器：通过接收并按照ingress定义的规则进行转发

　　ingress-nignx-controller：监听kube-apiserver接口，同步用户编写的ingress规则，动态的去更改nginx服务的配置文件，并且自动reload生效

　　ingress：将nginx的配置抽象成一个ingress对象，当用户每添加一个新的服务，只需要编写一个新的yaml文件即可

 

9、Flannel网络插件原理:

9.1、数据从源容器中发出后,经过所在主机的docker0虚拟网卡转发到flannel0虚拟网卡,这个是P2P的虚拟网卡,flannel服务监听在网卡的另外一端(另外的k8s机器)

9.2、Flannel通过Etcd服务维护一张节点间的路由表,详细记录了各节点子网络网段

9.3、源主机的flanneld服务将原来数据内容UDP封装后根据自己的路由表投递给目的节点的flannel服务

9.4、数据到达目的节点后被解包(flannel),然后直接进入目的节点的flannel0虚拟网卡,然后被转发到目的主机的docker0虚拟网卡,最后到达目标容器

流程如下:

container-01 👉 docker0 👉 (节点01)flannel0 👉 Flannel路由表 👉 (节点02)flannel0 👉 docker0 👉 container-02

 

 

10、k8s组件与api server的交互

10.1、kubelet与api server交互

kubelet通过reset接口报告自身状态,api server收到信息后,存放在etcd中,通过api server的watch接口监听pod信息,从而对pod进行管理

10.2、kube-controller-manager与api server交互

contoller-manage中的node contoller模块通过api server提供的watch接口实时监听node的信息

10.3、kube-scheduler 与 api server 交互

scheduler 通过api server的watch 接口监听到pod信息后,它会根据pod的要求选择node调度

 

11、Etcd备份和还原:

11.1、备份k8s集群文件 /etc/kubernetes/

11.2、备份etcd配置文件 /var/lib/etcd

11.3、基于快照备份etcd数据

声明export ETCDCTL_API=3

将etcd数据快照存储到指定文件

etcdctl —endpoints 127.0.0.1:2379 —cert=“” —key=“” —cacert=“” snapshot save 文件.db

11.4、查看快照

etcdctl snapshot status 快照名称.db

11.5、etcd还原

清理etcd数据目录

rm -rf /var/lib/etcd

Etcdctl snapshot restore 备份的数据文件 —-cacert=“” —cert=“” —key=“” —data-dir=/var/lib/etcd —endpoints=https://127.0.0.1:2379

 

12、端口type

12.1、NodePort: 可对外暴露应用

12.2、Cluster IP: Service的IP地址,虚拟IP地址

12.3、LoadBalancer大部分情况下只适用于支持外部负载均衡器的云提供商使用

 

13、Pod内容器通信:

同一个 Pod 内,所有容器共享存储、网络即使用同一个 IP 地址和端口空间，并且可以通过 localhost 发现对方.

Pod 使用了一个中间容器 Infra，Infra 在 Pod 中首先被创建，而其他容器则通过 Join Network Namespace 的方式与 Infra 容器关联在一起

 

13.1、Pod与Pod间的通信:

在同一台主机上时,通过node选择器调度在一起进行通信.

不在一起时,pod在不同主机的通信依赖于CNI插件,容器创建时的网络分配,容器删除时的网络资源释放

 

13.2、pod与services通信:

通过label标签进行绑定

 

13.3、services怎么做到服务发现的

Endpoints是k8s中的一种资源对象，k8s通过Endpoints监控到Pod的IP，service又关联Endpoints从而实现Pod的发现

 

14、更新k8s证书

手动更新 kubeadm certs renew,然后重启k8s组件,备份原来的证书

自动更新 kubeadm 会在控制面升级的时候更新所有证书

也可以用k8s api进行更新

 

15、监控类:

容器基础资源指标:

采集源为kubelet内置的cadvisor,提供容器内存,cpu,网络,文件等相关指标

例如：container_memory_xxxx

 

K8s节点资源指标:

Node_exporter提供节点系统和硬件相关的指标,节点总内存等等

例如: node_memory_xxxx

 

K8s资源指标:

采集源为kube-state-metrics,基于k8s api对象生成指标,提供k8s集群资源指标

例如:Node、ConfigMap、Deployment、DaemonSet 等类型.

以 Node 类型指标为例,包括节点 Ready 状态指标 kube_node_status_condition、节点信息kube_node_info 等等

 

K8s组件指标:

kube-controller-manager, kube-apiserver，kube-scheduler, kubelet，kube-proxy、coredns

blackbox_operator 可实现对用户自定义的探活规则定义

gpu_exporter 实现多gpu资源监控

 

prometheus 服务发现机制:

1、静态配置 - 手动在配置文件中配置

2、服务发现 - 动态发现需要监控target实例

静态服务发现 - static_configs

文件的方式

　　file_sd_configs

　　　　targets/目录/文件.json

　　kubernetes_sd_config

　　　　配置role定义发现目标(node/service/pod/endpoint/ingress)

配置样例: 以configmap的形式挂在配置文件

kind: ConfigMap

apiVersion: v1

metadata:

name: prometheus-config

data:

prometheus.yml: |-

global:

scrape_interval: 15s

evaluation_interval: 15s

scrape_configs:

- job_name: 'kubernetes-nodes'

tls_config:

ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt

bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token

kubernetes_sd_configs:

- role: node(service/pod/endpoint/ingress)

也可使用target对指定目标进行抓取

 

k8s天生支持promethues的指标采集,无须额外提供/metric接口;

在k8s环境中，promethues通过与k8s API集成完成自动发现功能,支持服务发现的模式包括:node、service、pod、endpoints、ingress

 

promethues 支持服务发现的来源类型包括：

kubernetes_sd_configs、file_sd_configs

 

16、存储卷:

pv和pvc的区别:

Pv是集群中由管理员配置的一段网络存储

Pvc是用户进行存储的请求

 

卷生命周期:

1、供给准备

2、绑定

3、释放

4、回收策略

retain,保留需要手动回收

recycle,回收自动删除卷中数据

delete,删除,相关的存储资产都会被删除

 

挂载卷的类型:

1、空目录

2、hostPath

3、pv+pvc

4、configmap secret

 

卷状态:

available 空闲资源

bound 绑定了pvc

released pvc已经删除,但pv没有被集群回收

Failed pv在自动回收中失败

 

pod的亲和性:

1、node节点亲和性,通过node标签设置

2、pod间的亲和性,指的是与某个pod在一起部署

 

pod的状态:

Pending：API Server已经创建该Pod，且Pod内还有一个或多个容器的镜像没有创建，包括正在下载镜像的过程

Running：Pod内所有容器均已创建，且至少有一个容器处于运行状态、正在启动状态或正在重启状态

Succeeded：Pod内所有容器均成功执行退出，且不会重启

Failed：Pod内所有容器均已退出，但至少有一个容器退出为失败状态

Unknown：由于某种原因无法获取该Pod状态，可能由于网络通信不畅导致

 

部署有状态的服务用 StatefulSet

无状态 deployment

日志收集、监控节点用 DaemonSet 

 

 

docker + jenkins + svn + harbor

 

1、提交代码 push

2、trigger 出发构建

3、build

4、push image to harbor

5、ssh remote

6、docker从harbor上拉取代码

 

准备工作：

1、拉取java8 docker镜像，将jenkins.war包cp到容器内，重启容器

2、将1步中打包的镜像上传到harbor

3、从harbor拉取镜像

 

测试:

1、创建jenkins项目

2、填写snv地址和用户验证

3、选择maven版本号，及docker命令行

post build action - 在send build artifacts over ssh 中填写要发布的ssh 机器名称,

定义源文件，远程目录，exec commnand中定义容器名称及端口等等

4、build测试