Kubernetes（k8s）使用及操作文档
https://kubernetes.io/zh/docs/reference/kubectl/overview/https://kubernetes.io/zh/docs/reference/kubectl/overview/#%E8%B5%84%E6%BA%90%E7%B1%B B%E5%9E%8Bhttps://kubernetes.io/zh/docs/reference/kubectl/
·
文章目录
一、基础
1、kubectl 常用命令
（1）总览
https://kubernetes.io/zh-cn/docs/reference/kubectl/
（2）kubectl命令补全
# 临时方案
yum -y install bash-completion
source /usr/share/bash-completion/bash_completion
source <(kubectl completion bash)
# 永久生效，退出终端也生效
kubectl completion bash > ~/.kube/completion.bash.inc
# vi修改~/.bash_profile，加上这一行
source '/root/.kube/completion.bash.inc'
# 使生效
source $HOME/.bash_profile
（3）node管理
# 查看集群信息
kubectl cluster-info
# 查看集群节点信息 -o wide 查看详细信息
kubectl get nodes -o wide
# 查看节点描述详细信息 加上node名
kubectl describe node node-12
# 查看节点标签
kubectl get node --show-labels
# 设置标签
kubectl label node node-12 region=qingdao
# 查看所有带region标签的节点
kubectl get nodes -L region
# 设置多维度标签
kubectl label node node-13 zone=A env=test bussiness=game
# 显示节点标签
kubectl get nodes -L region,zone
# 查找region=qingdao的节点
kubectl get nodes -l region=qingdao
# 修改标签--overwrite=true 覆盖原有标签
kubectl label node node-12 bussiness=admin --overwrite=true
# 删除标签 用key加一个减号
kubectl label node node-12 region-
# 标签选择器
# 等值关系： = !=
# 集合关系 KEY in(VALUE1, VALUE2 ... )
kubectl label node node-12 env=test1
kubectl label node node-13 env=test2
kubectl get node -l "env in(test1, test2)"
（4）namespace命名空间
NameSpace是对一组资源和对象的抽象集合，常见的pod、service、deployment等都是属于某一个namespace的（默认是default）。
但是nodes、persistent volume等不属于namespace
# 查看namespace
kubectl get namespaces
kubectl get ns
# 查看namespace资源
kubectl get all -n kube-system
kubectl get all --namespace kube-system
kubectl get pods -n kube-system
# 查看所有命名空间的资源
kubectl get pods -A
# 创建namespace
kubectl create namespace n1
# 删除namespace，之下的所有资源都会删除，谨慎操作。default、kube-system、kube-public不可删除
kubecel delete namespace n1
（5）pod
# 查看pods，指定命名空间
kubectl get pods -n default
# 详细内容
kubectl get pods -o wide -n default
# 详细内容 指定pod名xxxx
kubectl describe pod xxxx -o wide -n default
# 删除pod
kubectl delete pod pod-stress -n default
kubectl delete pod pod pod1 pod2
kubectl delete -f pod1.yml
# 查看日志
# 返回 Pod <pod-name> 的日志快照。
kubectl logs <pod-name>
# 从 Pod <pod-name> 开始流式传输日志。这类似于 'tail -f' Linux 命令。
kubectl logs -f <pod-name>
# 从 Pod <pod-name> 中获取运行 'date' 的输出。默认情况下，输出来自第一个容器。
kubectl exec <pod-name> -- date
# 运行输出 'date' 获取在 Pod <pod-name> 中容器 <container-name> 的输出。
kubectl exec <pod-name> -c <container-name> -- date
# 获取一个交互 TTY 并在 Pod <pod-name> 中运行 /bin/bash。默认情况下，输出来自第一个容器。
kubectl exec -ti <pod-name> -- /bin/bash
（6）controller：deployment
# 查看deployment
kubectl get deployment -n app
kubectl get deploy -n app
kubectl get deployment.apps -n app
# 查看副本集
kubectl get replicaset -n app
# 在controller中删除pod之后，controller会自动再启动一个
kubectl delete pod xxxxx -n app
# 删除deployment就会删除里面的pod
kubectl delete deployment xxxx -n app
# 升级pod版本
# 查看pod镜像版本
kubectl describe pods appdep-5bbccf7b6d-5llcm -n app | grep Image:
# 更新版本
# deployment deploy-nginx：代表deploy-nginx的deployment
# nginx=nginx:1.16 前面的nginx为容器名
# --record 表示会记录
kubectl set image deployment deploy-nginx nginx=nginx:1.16 --record
# 查看容器名的方式
kubectl describe pod xxxx -n app
kubectl edit deployment appdep -n app
kubectl get deployment xxxx -o yaml -n app
# 查看是否升级成功
kubectl rollout status deployment 名称 -n app
# pod版本回退
# 查看版本历史信息
kubectl rollout history deployment deploy-nginx
# 定义要回退的版本
kubectl rollout history deployment deploy-nginx --revision=1
# 执行回退
kubectl rollout undo deployment deploy-nginx --to-revision=1
# 验证
kubectl rollout history deployment deploy-nginx
# 扩容为2个副本
kubectl scale deployment deploy-nginx --replicas=2 -n app
# 查看pod
kubectl get pods -o wide -n app
# 缩减为1个副本
kubectl scale deployment deploy-nginx --replicas=1 -n app
# 多副本滚动更新，有多副本就会执行滚动更新
kubectl set image deployment deploy-nginx nginx=nginx:1.16 --record
（7）service
# 查看service
kubectl get service -n app
kubectl get svc -n app
# 查看端点
kubectl get endpoints -n app
# 命令行创建ClusterIP service
# expose 创建service
# deployment.apps 控制器类型
# nginx-server1 应用名称，也是service名称
# --type=ClusterIP 指定service类型
# --target-port=80 指定Pod中容器端口
# --port=80 指定service端口
kubectl expose deployment.apps nginx-server1 --type=ClusterIP --target-port=80 --port=80
2、k8s配置master运行pod
出于安全考虑，默认配置下Kubernetes不会将Pod调度到Master节点。
也可以控制台查看污点。
#查看k8s-master表示不运行pod
[root@k8s-master ~]# kubectl describe node k8s-master |grep Taints
Taints: node-role.kubernetes.io/master:NoSchedule
#查看k8s-master表示运行pod
[root@k8s-master ~]# kubectl describe node k8s-master |grep Taints
Taints: <none>
#让 master节点参与POD负载的命令为
kubectl taint nodes k8s-master node-role.kubernetes.io/master-
#让 master节点恢复不参与POD负载的命令为
kubectl taint nodes k8s-master node-role.kubernetes.io/master=:NoSchedule
注意：我的Taints: node-role.kubernetes.io/control-plane:NoSchedule
3、yml文件
（1）文档
（2）kubectl处理yml
# 应用yml
kubectl apply -f test.yml
# 删除
kubectl delete -f test.yml
4、worker node节点管理集群
# node节点家目录创建.kube目录
mkdir /root/.kube
# master节点操作
scp /etc/kubernetes/admin.conf node-12:/root/.kube/config
# node节点验证
kubectl get nodes
5、pod生命周期
（1）容器重启策略
Always：表示容器挂了总是重启，这是默认策略。
OnFailures：容器状态为错误时才重启，也就是容器正常终止时不重启
Never：表示容器挂了不予重启。
对于Always这种策略，容器只要挂了，就会立即重启，这样是很耗费资源的。所以Always重启策略是这么做的：第一次容器挂了立即重启，如果再挂了就要延时10s重启，第三次挂了就等20s重启.… 依次类推
（2）健康检查的探针与检查方式
pod中的容器在创建前，有初始化容器(init container)来进行初始化环境。初始化完后，主容器（main container）廾始启动。
主容器启动后，有一个post start的操作(启动后的触发型操作，或者叫启动后钩子)。
post start后，就开始做健康检査。
第一个健康检查叫存活状态检查(liveness probe)，用来检查主容器存活状态的。
第二个健康检查叫准备就绪检查(readiness probe)，用来检查主容器是否启动就绪。
可以在容器终止前设置pre stop操作(终止前的触发型操作，或者叫终止前钩子)。当出现特殊情况不能正常销毁pod时，大概等待30秒会强制终止。终止容器后还可能会重启容器(视容器重启策略而定)。
| 方式 | 说明 |
|---|---|
| Liveness Probe(存活状态探测) | 指示容器是否正在运行。如果存活态探测失败，则 kubelet 会杀死容器， 并且容器将根据其重启策略决定未来。如果容器不提供存活探针， 则默认状态为 Success。 |
| readiness Probe(就绪型探测) | 指示容器是否准备好为请求提供服务。如果就绪态探测失败， 端点控制器将从与 Pod 匹配的所有服务的端点列表中删除该 Pod 的 IP 地址。 初始延迟之前的就绪态的状态值默认为 Failure。 如果容器不提供就绪态探针，则默认状态为 Success。注：检查后不健康，将容器设置为Notready;如果使用service来访问,流量不会转发给此种状态的pod |
| startup Probe | 指示容器中的应用是否已经启动。如果提供了启动探针，则所有其他探针都会被 禁用，直到此探针成功为止。如果启动探测失败，kubelet 将杀死容器，而容器依其 重启策略进行重启。 如果容器没有提供启动探测，则默认状态为 Success。 |
| 方式 | 说明 |
|---|---|
| Exec | 执行命令 |
| HTTPGet | http请求某一个URL路径 |
| TCP | tcp连接某一个端口 |
| gRPC | 使用 gRPC 执行一个远程过程调用。 目标应该实现 gRPC健康检查。 如果响应的状态是 “SERVING”，则认为诊断成功。 gRPC 探针是一个 alpha 特性，只有在你启用了 “GRPCContainerProbe” 特性门控时才能使用。 |
官方文档：
https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
（3）post-start、pre-stop
容器启动前和停止前执行的操作：
apiVersion: v1
kind: Pod
metadata:
name: prestop
namespace: default
spec:
containers:
- name: prestop
image: nginx:1.15-alpine
imagePullPolicy: IfNotPresent
lifecycle: # 生命周期事件
preStop: # preStop
exec:
command: ["/bin/sh","-c","sleep 60000000"] # 容器终止前sleep 60000000秒
postStart:
exec:
command: ["mkdir","-p","/usr/share/nginx/html/haha"]
二、运维踩坑
1、service修改为ipvs调度方式（拓展）
部署方式不同，修改方法不一样。
本次主要介绍使用kubeadm部署集群方式，二进制部署较为简单。
二进制部署修改：/etc/kubernetes/kube-proxy.yaml文件即可。
从kubernetes1.8版本开始，新增了kube-proxy对ipvs的支持，在kubernetes1.11版本中被纳入了GA。
现使用Centos7u6发布版本，默认内核版本为3.10.0，使用kubernetes为1.18.0时，可升级内核版本至4.18.0或5.6.0版本。
在所有节点中安装,需要重启操作系统更换内核。以下升级方法供参考。
# 1、升级内核
[root@localhost ~]# yum -y install perl
[root@localhost ~]# rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org
[root@localhost ~]# yum -y install https://www.elrepo.org/elrepo-release-7.0-4.el7.elrepo.noarch.rpm
[root@localhost ~]# yum --enablerepo="elrepo-kernel" -y install kernel-ml.x86_64
此处升级为5.0以上版本。
[root@localhost ~]# grub2-set-default 0
[root@localhost ~]# grub2-mkconfig -o /boot/grub2/grub.cfg
[root@localhost ~]# reboot
# 2、修改kube-proxy的配置文件
[root@master01 ~]# kubectl edit configmap kube-proxy -n kube-system
26 iptables:
27 masqueradeAll: false
28 masqueradeBit: 14
29 minSyncPeriod: 0s
30 syncPeriod: 30s
31 ipvs:
32 excludeCIDRs: null
33 minSyncPeriod: 0s
34 scheduler: "" # 可以在这里修改ipvs的算法,默认为rr轮循算法
35 strictARP: true
36 syncPeriod: 30s
37 kind: KubeProxyConfiguration
38 metricsBindAddress: 127.0.0.1:10249
39 mode: "ipvs" # 默认""号里为空,加上ipvs
# 3、查看kube-system的namespace中kube-proxy有关的pod
[root@master01 ~]# kubectl get pods -n kube-system |grep kube-proxy
kube-proxy-69mv6 1/1 Running 6 2d18h
kube-proxy-jpc6c 1/1 Running 4 4d16h
kube-proxy-kq65l 1/1 Running 4 4d16h
kube-proxy-lmphf 1/1 Running 5 4d16h
# 4、验证kube-proxy-xxx的pod中的信息
[root@master01 ~]# kubectl logs kube-proxy-jpc6c -n kube-system
W0517 00:55:10.914754 1 server_others.go:559] Unknown proxy mode "", assuming iptables proxy
I0517 00:55:10.923228 1 node.go:136] Successfully retrieved node IP: 192.168.122.32
I0517 00:55:10.923264 1 server_others.go:186] Using iptables Proxier.
I0517 00:55:10.923567 1 server.go:583] Version: v1.18.2
I0517 00:55:10.923965 1 conntrack.go:100] Set sysctl 'net/netfilter/nf_conntrack_max' to 131072
I0517 00:55:10.924001 1 conntrack.go:52] Setting nf_conntrack_max to 131072
I0517 00:55:10.924258 1 conntrack.go:83] Setting conntrack hashsize to 32768
I0517 00:55:10.927041 1 conntrack.go:100] Set sysctl 'net/netfilter/nf_conntrack_tcp_timeout_established' to 86400
I0517 00:55:10.927086 1 conntrack.go:100] Set sysctl 'net/netfilter/nf_conntrack_tcp_timeout_close_wait' to 3600
I0517 00:55:10.927540 1 config.go:315] Starting service config controller
I0517 00:55:10.927556 1 shared_informer.go:223] Waiting for caches to sync for service config
I0517 00:55:10.927576 1 config.go:133] Starting endpoints config controller
I0517 00:55:10.927594 1 shared_informer.go:223] Waiting for caches to sync for endpoints config
I0517 00:55:11.027749 1 shared_informer.go:230] Caches are synced for service config
I0517 00:55:11.027858 1 shared_informer.go:230] Caches are synced for endpoints config
# 5、重新启动kube-proxy
# 删除kube-proxy-xxx的所有pod，让它重新拉取新的kube-proxy-xxx的pod
[root@master01 ~]# kubectl delete pod kube-proxy-69mv6 -n kube-system
pod "kube-proxy-69mv6" deleted
[root@master01 ~]# kubectl delete pod kube-proxy-jpc6c -n kube-system
pod "kube-proxy-jpc6c" deleted
[root@master01 ~]# kubectl delete pod kube-proxy-kq65l -n kube-system
pod "kube-proxy-kq65l" deleted
[root@master01 ~]# kubectl delete pod kube-proxy-lmphf -n kube-system
pod "kube-proxy-lmphf" deleted
[root@master01 ~]# kubectl get pods -n kube-system |grep kube-proxy
kube-proxy-2mk2b 1/1 Running 0 2m23s
kube-proxy-5bj87 1/1 Running 0 30s
kube-proxy-7qq9l 1/1 Running 0 52s
kube-proxy-tjtqf 1/1 Running 0 80s
# 6、随意查看其中1个或3个kube-proxy-xxx的pod,验证是否为IPVS方式了
[root@master1 ~]# kubectl logs kube-proxy-tjtqf -n kube-system
I0517 02:32:26.557696 1 node.go:136] Successfully retrieved node IP: 192.168.122.32
I0517 02:32:26.557745 1 server_others.go:259] Using ipvs Proxier.
W0517 02:32:26.557912 1 proxier.go:429] IPVS scheduler not specified, use rr by default
I0517 02:32:26.560008 1 server.go:583] Version: v1.18.2
I0517 02:32:26.560428 1 conntrack.go:52] Setting nf_conntrack_max to 131072
I0517 02:32:26.561094 1 config.go:315] Starting service config controller
I0517 02:32:26.562251 1 shared_informer.go:223] Waiting for caches to sync for service config
I0517 02:32:26.561579 1 config.go:133] Starting endpoints config controller
I0517 02:32:26.562271 1 shared_informer.go:223] Waiting for caches to sync for endpoints config
I0517 02:32:26.662541 1 shared_informer.go:230] Caches are synced for service config
I0517 02:32:26.662566 1 shared_informer.go:230] Caches are synced for endpoints config
参考文档
POD：https://blog.csdn.net/weixin_44933490/article/details/135426193
K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容
更多推荐
2
0- 0
已为社区贡献7条内容
所有评论(0)