Kubernetes-面试题
1、Docker和虚拟机有哪些不同？
Docker是轻量级的沙盒,在其中运行的只是应用,而虚拟机里面还有额外独立的系统
2、简述Kubernetes和Docker的关系？
Docker 通过dockerfile
将应用程序运行所需的设置和依赖打包到一个容器中,从而实现了可移植性等优点
Kubernetes 用于关联和编排在多个主机上运行的容器
3、简述Kube-proxy ipvs和iptables的异同？
iptables 是为防火墙而设计的;
IPVS则专门用于高性能负载均衡,并使用更高效的数据结构(Hash表),允许无限的规模扩张
与iptables相比, IPVS拥有以下明显优势:
1、为大型集群提供了更好的可扩展性和性能;
2、支持比iptables更复杂的复制均衡算法(最小负载、最少连接、加权等);
3、支持服务器健康检查和连接重试等功能;
4、可以动态修改ipset的集合,
4、简述Kube-proxy切换为ipvs负载？
5、简述微服务部署中的蓝绿发布？
蓝绿发布(Blue/Green Deployment)
蓝绿部署中,一共有两套系统:一套是正在提供服务系统,标记为"绿色";另一套是准备发布的系统,标记为"蓝色"
两套系统都是功能完善的、正在运行的系统,只是系统版本和对外服务情况不同。
开发新版本,要用新版本替换线上的旧版本,在线上的系统之外,搭建了一个使用新版本代码的全新系统。
这时候,一共有两套系统在运行,正在对外提供服务的老系统是绿色系统,新部署的系统是蓝色系统。
蓝色系统不对外提供服务,用来做什么呢?用来做发布前测试,测试过程中发现任何问题,可以直接在蓝色系统上修改,不干扰用户正在使用绿色的系统
蓝色系统经过反复的测试、修改、验证,确定达到上线标准之后,直接将用户切换到蓝色系统(这也是软件测试人员最爱的发布方式"用简单粗暴来形容毫不为过")
在项目选代的过程中,不可避免需要上线
上线对应着部署,或者重新部署;部署对应着修改,修改则意味着所以蓝绿部署是不停老版本,部署新版本然后进行测试。
确认OK后将流量切到新版本
特点：
蓝绿部署无需停机,并且风险最小
6、简述蓝绿发布的优缺点？
优势和不足
优势升级切换和回退速度非常快
不足
切换是全量的,如果V2版本有问题,则对用户体验有直接影响。
需要两倍机器资源。
7、简述Kubernetes静态pod？
# 静体现在哪里？
之前: 前而iPod的'生命周期管理'
都是通过像Daemonset、 Statefulset、Deployment'上层'这种方式创建管理的
静态Pod是由kubelet进行管理'仅存在于特定Node上'的Pod -->'可以理解为定向调度”
它们'不能通过API Server'进行管理,无法与'Replicationcontroller',
'Deployment'或'DaemonSet'进行'关联'-->'就是一个Pod',并且kubelet也无法对其'健康检查”
总结: 是静态Pod总是'由kubelet进行创建',并且总是'在kubelet所在的Node上,运行的
kubeadm安装的k8s集群
配置文件路径: `/var/1ib/kubelet/config.yaml`
二进制文件安装的k8s集群
配置文件路径: `/usr/lib/systemd/system/kubelet.service`
在文件中添加一行 `--pod-manifest-path=`
image.png
作用机理：
-
如果把
pod的yaml描述文件放到这个目录中,等kubelet扫描到文件,会自动在本机-->也就是文件所在node的kubelet创建pod -
如果把pod的yaml
文件更改了,kubelet也会识别到,会自动更新pod -
如果把pod的
yaml文件删除了,kubelet公自动删除掉pod -
因为静态pod
不能被apli-server 直接管理,所以它的更新删除操作不能由kubectl来执行,只能直接修改或删除文本文件
备注:但是在etcd数据库会进行记录
8、简述Kubernetes数据持久化的方式有哪些？
1）emptydir空目录临时存储
2）hostpath docker bind mount 挂载宿主机目录
3）pv nfs gfs ceph
9、简述Dockerfile中copy和add指令有什么区别？
copy：文件复制
add：复制文件并且解压缩 支持url
10、如何为k8s集群添加新的节点？
1）k8s node节点硬件物理故障如何维护方法
为何呢？在节点物理故障移除故障节点并重新添加新的运行节点
2）那么如何处理？
删除节点操作
kubectl delete nodes k8s-node-02
在被删除的node节点中清空集群数据信息
kubeadm reset
重新加入集群，在集群中常见临时令牌并查token值
在k8s-master-01机器上执行命令
kubeadm token create --print-join-commandkubeadm join 192.168.5.150:6443 --token sdfjv6.06jmct5nlrteediy --discovery-token-ca-cert-hashsha256:30845511f229ef041d6016feOea5988c2794f77 cab33962695b883d9f90b2a39
在节点端重新加入
在k8s-node-02机器上执行命令
kubeadm join 192.168.5.150:6443 --token sdfjv6.06jmct5nlrteediy --discovery-token-cacert-hash sha256:30845511f229ef041d6016feOea5988c2794f77cab33962695b883d9f90b2a39
平滑删除pod
目标数量掌握添加删除k8s node节点，永久token生成
在k8s-master-01机器上执行命令
kubeadm token create --print-join-command --ttl 0
kubeadm token list
此token的有有效期为永久有效。为了安全起见,建议使用临时token,而不要使用永久的token
使用kubectl drain (排干) ,将指定删除的节点上的资源迁移至集群中的其它节点上,以下以k8s-node-02为例
kubectl drain k8s-node-02 --delete-1ocal-data --force --ignore-daemonsets
kubect1 delete node k8s-node-02
到k8s-node-02端彻底清空集群数据信息
kubeadm reset -f
systemctl stop kubelet
systemct1 stop docker
rm -rf /var/lib/cni/
rm -rf /var/lib/kubelet/*
rm -rf /etc/cni/
ifconfig cnio down
ifconfig flannel.1 down
ifconfig docker0 down
ip link delete cni0
ip link delete flannel.1
systemctl start docker
iptables -F && sudo iptables -t nat -F && sudo iptables -t mangle -F && sudo iptables -X
ipvsadm -C
重新加入集群
#到master端查看令牌
kubeadm token list
openss1 x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2>/dev/null | openssl dgst -sha256 -hex | sed 's/^.* //'
11、自定义svc端口报错是什么原因？
kubectl创建pod实例:
kubectl create deployment nginx --image=nginx
kubectl get pod -n default -o widekubectl get deployments.apps
kubectl get deployments.apps
kubectl expose deployment nginx --port=80 --type=NodePort
kubectl get pod,svc
测试使用curl进行测试
curl 192.168.3.165:31000
解决办法：
修改NodePort的范围使用
kubeadm 安装 K8S 集群的情况下,您的Master节点上会有一个文件
/etc/kubernetes/manifests/kube-apiserver.yaml
修改此文件,向其中添加--service-node-port-range=30000-42767
--tls-private-key-file=/etc/kubernetes/pki/apiserver.key
--service-node-port-range=30000-42767
...
State:Running
Started:Fri, 20 May 2022 03:58:16 +0800
Ready:TrueRestart Count: 0
Requests:
cpu:250m
...
修改完成后要重启apiserver否则集群直接垮掉,需要重启apiserver
以下有两种方法重启：
1) 如果是`kubeadm`部署`kubernetes`，需要使用以下命令：`systemctl restart kubelet`重启`kubernetes`集群
2) 获取apiserver_pods的名，然后直接删除
export apiserver_pods=$(kubectl get pods --selector=component=kube-apiserver -n kube-system --output=jsonpath={.items..metadata.name})
kubectl delete pod $apiserver_pods -n kube-system
12、简述k8s常用控制器及特点？
1.Deployment 部署无状态应用部署1个Pod起
2.StatefulSet 部署有状态应用部署1个Pod起
3.DaemonSet 每台主机部署1个Pod
4.cronjob 定时运行Pod
5.job 一次性运行Pod
13、k8s拉伸收缩副本失败-怎么办？
14、node容忍节点异常时间如何设置?
15、简述Kubernetes deployment升级过程
初始创建Deployment时，系统创建了一个ReplicaSet，并按用户的需求创建了对应数量的Pod副本。
当更新Deployment时，系统创建了一个新的ReplicaSet，并将其副本数量扩展到1，然后将旧ReplicaSet缩减为2。
之后，系统继续按照相同的更新策略对新旧两个ReplicaSet进行逐个调整。
最后，新的ReplicaSet运行了对应个新版本Pod副本，旧的ReplicaSet副本数量则缩减为0。
16、简述Kubernetes deployment升级策略
在Deployment的定义中，可以通过spec.strategy指定Pod更新的策略，目前支持两种策略：Recreate（重建）和RollingUpdate（滚动更新），默认值为RollingUpdate。
Recreate：设置spec.strategy.type=Recreate，表示Deployment在更新Pod时，会先杀掉所有正在运行的Pod，然后创建新的Pod。
RollingUpdate：设置spec.strategy.type=RollingUpdate，表示Deployment会以滚动更新的方式来逐个更新Pod。同时，可以通过设置spec.strategy.rollingUpdate下的两个参数（maxUnavailable和maxSurge）来控制滚动更新的过程。
17、请简述deployment控制器的升级和回滚?
1) 升级pod
kubectl set image deployment/nginx-deployment nginx=nginx:latest
比如：假设我们在整个升级的过程中，系统会保证至少有两个Pod可用，并且最多同时运行4个Pod，这是Deployment通过复杂的算法完成的。Deployment需要确保在整个更新过程中只有一定数量的Pod可能处于不可用状态。在默认情况下，Deployment确保可用的Pod总数至少为所需的副本数量（DESIRED）减1，也就是最多1个不可用（maxUnavailable=1）。Deployment还需要确保在整个更新过程中Pod的总数量不会超过所需的副本数量太多。在默认情况下，Deployment确保Pod的总数最多比所需的Pod数多1个，也就是最多1个（maxSurge=1）。Kubernetes从1.6版本开始，maxUnavailable和maxSurge的默认值将从1、1更新为所需副本数量的25%、25%。这样，在升级过程中，Deployment就能够保证服务不中断，并且副本数量始终维持为用户指定的数量（DESIRED）。
在Deployment的定义中，可以通过spec.strategy指定Pod更新的策略，目前支持两种策略：Recreate（重建）和RollingUpdate（滚动更新），默认值为RollingUpdate。在前面的例子中使用的就是RollingUpdate策略。
- Recreate：设置spec.strategy.type=Recreate，表示Deployment在更新Pod时，会先杀掉所有正在运行的Pod，然后创建新的Pod
- RollingUpdate：设置spec.strategy.type=RollingUpdate，表示Deployment会以滚动更新的方式来逐个更新Pod。同时，可以通过设置spec.strategy.rollingUpdate下的两个参数（maxUnavailable和maxSurge）来控制滚动更新的过程。
spec.strategy.rollingUpdate.maxUnavailable：用于指定Deployment在更新过程中不可用状态的Pod数量的上限。该maxUnavailable的数值可以是绝对值（例如5）或Pod期望的副本数的百分比（例如10%），如果被设置为百分比，那么系统会先以向下取整的方式计算出绝对值（整数）。而当另一个参数maxSurge被设置为0时，maxUnavailable则必须被设置为绝对数值大于0（从Kubernetes 1.6开始，maxUnavailable的默认值从1改为25%）。举例来说，当maxUnavailable被设置为30%时，旧的ReplicaSet可以在滚动更新开始时立即将副本数缩小到所需副本总数的70%。一旦新的Pod创建并准备好，旧的ReplicaSet会进一步缩容，新的ReplicaSet又继续扩容，整个过程中系统在任意时刻都可以确保可用状态的Pod总数至少占Pod期望副本总数的70%
spec.strategy.rollingUpdate.maxSurge：用于指定在Deployment更新Pod的过程中Pod总数超过Pod期望副本数部分的最大值。该maxSurge的数值可以是绝对值（例如5）或Pod期望副本数的百分比（例如10%）。如果设置为百分比，那么系统会先按照向上取整的方式计算出绝对数值（整数）。从Kubernetes 1.6开始，maxSurge的默认值从1改为25%。举例来说，当maxSurge的值被设置为30%时，新的ReplicaSet可以在滚动更新开始时立即进行副本数扩容，只需要保证新旧ReplicaSet的Pod副本数之和不超过期望副本数的130%即可。一旦旧的Pod被杀掉，新的ReplicaSet就会进一步扩容。在整个过程中系统在任意时刻都能确保新旧ReplicaSet的Pod副本总数之和不超过所需副本数的130%。
2) 回滚pod
为了能解决发布部署这个问题，我们需要回滚到之前稳定版本的Deployment。首先，用kubectl rollout history命令检查这个Deployment部署的历史记录：
kubectl rollout history deployment/nginx-deployment
image.png
撤销本次发布并回滚到上一个部署版本
kubectl rollout undo deployment/nginx-deployment
也可以使用–to-revision参数指定回滚到的部署版本号：
kubectl rollout undo deployment/nginx-deployment --to-revision=1
这样，该Deployment就回滚到之前的稳定版本了，可以从 Deployment的事件信息中查看到回滚到版本1的操作过程
kubectl describe deployment nginx-deployment
此时可以看到nginx-deployment具体的回滚过程，并可以看到当前镜像已回退到nginx:1.7.9版本
image.png
18、请说出一套Kubernetes合理决绝日志收集资源监控等常用配置需求的解决方案
19、监控Docker命令是什么?
docker自带了三个监控命令即ps, top, stats
1) ps
docker ps 可以帮助我们很快的了解当前正在运行的容器
-a:会显示已经停掉的容器
[root@host1 ~]# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
2dc535903c8f weaveworks/scope:1.10.1 "/home/weave/entrypo…" 14 minutes ago Up 14 minutes weavescope
9c0b7af8f210 busybox "sh" 38 minutes ago Up 38 minutes b10
39e40500da10 busybox "sh" 38 minutes ago Up 38 minutes b9
3f5f98e0c5d2 busybox "sh" 38 minutes ago Up 38 minutes b8
a0cef436f61a busybox "sh" 38 minutes ago Up 38 minutes b7</pre>
2) top
如果想知道某个容器中运行了哪些进程，可以执行如下的命令：
[root@host1 ~]# docker top 266910b9b
UID PID PPID C STIME TTY TIME CMD
root 7162 7144 0 14:55 pts/0 00:00:00 sh
3) stats
用于显示每个容器各种资源的使用情况
而且是动态刷新的
[root@host1 ~]# docker stats 266910b9b
CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
266910b9bede b3 0.00% 52KiB / 487.5MiB 0.01% 978B / 280B 1.97MB / 8.19kB 1
ps，top, stats 这几个命令是 docker 自带的，优点是运行方便，很适合想快速了解容器运行状态的场景。其缺点是输出的数据有限，而且都是实时数据，无法反应历史变化和趋势。接下来要介绍的几个监控工具会提供更丰富的功能。
还有一个是sysdig，它是一个轻量级的系统监控工具，同时它还原生支持容器
