K8S使用手册
概念理解
Pod概念
①Pod是Kubernetes中一个抽象化概念，由一个或多个容器组合在一起得共享资源。这些资源包括：
1)共享存储，如 Volumes 卷
2)网络，唯一的集群IP地址
3)每个容器运行的信息，例如:容器镜像版本
②Pod理解
Pod模型是特定应用程序的“逻辑主机”，并且包含紧密耦合的不同应用容器。
Pod中的容器共享IP地址和端口。
组件
使用proxy监听端口
[root@tke-node1 ~]# kubectl proxy --port=8080 &
[root@tke-node1 ~]# curl http://localhost:8080/api/
{
"kind": "APIVersions",
"versions": [
"v1"
],
"serverAddressByClientCIDRs": [
{
"clientCIDR": "0.0.0.0/0",
"serverAddress": "cls-2kj2mgeq.ccs.tencent-cloud.com:60002"
}
]
}
组件关系
kubelet单独运行，因为要和宿主机直接打交道。然后通过静态pod启动三大组件。
各类IP
NodeIP：主机IP；
ClusterIP：ServcieIP即VIP；
PodIP：Pod的IP。
各类端口
NodePort：主机上监听的端口；
Port：service中clusterIP 对应的端口。
TargetPort：ClusterIP作为负载均衡， 后端目标实例(容器)的端口。指后端pod暴露的端口，就是pod中的containerPort。
如果既不指定port又不指定targetPort，那么port和targetPort都会继承pod中的containerPort。
如果指定了port而没有指定targetPort，那么targetPort会继承port值，所以此时必须指定targetPort值为pod中的containerPort，不能随便指定端口号，除非port值和pod中的containerPort相同（这种情况可以不指定targetPort）。
当type为ClusterIP时，流量经过的端口走向是：svc端口（port）----pod端口（targetPort）----容器端口（containerPort）
当type为NodePort时，流量经过的端口走向是：节点端口（NodePort）----svc端口（port）----pod端口（targetPort）----容器端口（containerPort）
EndPoint为podIP:targetPort：即每个Service的所有Endpoints
Service 的几种类型
ClusterIp：默认类型，每个Node分配一个集群内部的Ip，内部可以互相访问，外部无法访问集群内部。
NodePort：基于ClusterIp，另外在每个Node上开放一个端口，可以从所有的位置访问这个地址。
LoadBalance：基于NodePort，并且有云服务商在外部创建了一个负载均衡层，将流量导入到对应Port。要收费的。
ExternalName：将外部地址经过集群内部的再一次封装(实际上就是集群DNS服务器将CNAME解析到了外部地址上)，实现了集群内部访问即可。
Ingress：通过独立的ingress对象来制定请求转发的规则，把请求路由到一个或多个service中。这样就把服务与请求规则解耦了。
资源状态
kubernetes:
node:
- TerminatedAllPods # Terminated All Pods (information)
- RegisteredNode # Node Registered (information)*
- RemovingNode # Removing Node (information)*
- DeletingNode # Deleting Node (information)*
- DeletingAllPods # Deleting All Pods (information)
- TerminatingEvictedPod # Terminating Evicted Pod (information)*
- NodeReady # Node Ready (information)*
- NodeNotReady # Node not Ready (information)*
- NodeSchedulable # Node is Schedulable (information)*
- NodeNotSchedulable # Node is not Schedulable (information)*
- CIDRNotAvailable # CIDR not Available (information)*
- CIDRAssignmentFailed # CIDR Assignment Failed (information)*
- Starting # Starting Kubelet (information)*
- KubeletSetupFailed # Kubelet Setup Failed (warning)*
- FailedMount # Volume Mount Failed (warning)*
- NodeSelectorMismatching # Node Selector Mismatch (warning)*
- InsufficientFreeCPU # Insufficient Free CPU (warning)*
- InsufficientFreeMemory # Insufficient Free Mem (warning)*
- OutOfDisk # Out of Disk (information)*
- HostNetworkNotSupported # Host Ntw not Supported (warning)*
- NilShaper # Undefined Shaper (warning)*
- Rebooted # Node Rebooted (warning)*
- NodeHasSufficientDisk # Node Has Sufficient Disk (information)*
- NodeOutOfDisk # Node Out of Disk Space (information)*
- InvalidDiskCapacity # Invalid Disk Capacity (warning)*
- FreeDiskSpaceFailed # Free Disk Space Failed (warning)*
pod:
- Pulling # Pulling Container Image (information)
- Pulled # Ctr Img Pulled (information)
- Failed # Ctr Img Pull/Create/Start Fail (warning)*
- InspectFailed # Ctr Img Inspect Failed (warning)*
- ErrImageNeverPull # Ctr Img NeverPull Policy Violate (warning)*
- BackOff # Back Off Ctr Start, Image Pull (warning)
- Created # Container Created (information)
- Started # Container Started (information)
- Killing # Killing Container (information)*
- Unhealthy # Container Unhealthy (warning)
- FailedSync # Pod Sync Failed (warning)
- FailedValidation # Failed Pod Config Validation (warning)
- OutOfDisk # Out of Disk (information)*
- HostPortConflict # Host/Port Conflict (warning)*
replicationController:
- SuccessfulCreate # Pod Created (information)*
- FailedCreate # Pod Create Failed (warning)*
- SuccessfulDelete # Pod Deleted (information)*
- FailedDelete # Pod Delete Failed (warning)*
服务质量
Kubernetes 创建 Pod 时就给它指定了下列⼀种 QoS 类：
-
Best-Effort ，最低优先级，第⼀个被kill。
-
Burstable ，第⼆个被kill。
-
Guaranteed ，最⾼优先级，最后kill。除⾮超过limit或者没有其他低优先级的Pod。
命令和参数
如果在使用K8S创建服务时，填写了容器得运行命令和参数，容器服务将会覆盖镜像构建时的默认命令（即Entrypoint和CMD），规则如下：
资源对象
PodPreset
这个需求实际上非常实用。比如，开发人员只需要提交一个基本的、非常简单的 Pod YAML，Kubernetes 就可以自动给对应的 Pod 对象加上其他必要的信息，比如 labels，annotations，volumes 等等。而这些信息，可以是运维人员事先定义好的。这么一来，开发人员编写 Pod YAML 的门槛，就被大大降低了
所以，这个叫作 PodPreset（Pod 预设置）的功能 已经出现在了 v1.11 版本的 Kubernetes 中。
举个例子，现在开发人员编写了如下一个 pod.yaml 文件：
apiVersion: v1
kind: Pod
metadata:
name: website
labels:
app: website
role: frontend
spec:
containers:
- name: website
image: nginx
ports:
- containerPort: 80
作为 Kubernetes 的初学者，你肯定眼前一亮：这不就是我最擅长编写的、最简单的 Pod 嘛。没错，这个 YAML 文件里的字段，想必你现在闭着眼睛也能写出来。
可是，如果运维人员看到了这个 Pod，他一定会连连摇头：这种 Pod 在生产环境里根本不能用啊！
所以，这个时候，运维人员就可以定义一个 PodPreset 对象。在这个对象中，凡是他想在开发人员编写的 Pod 里追加的字段，都可以预先定义好。比如这个 preset.yaml：
apiVersion: settings.k8s.io/v1alpha1
kind: PodPreset
metadata:
name: allow-database
spec:
selector:
matchLabels:
role: frontend
env:
- name: DB_PORT
value: "6379"
volumeMounts:
- mountPath: /cache
name: cache-volume
volumes:
- name: cache-volume
emptyDir: {}
在这个 PodPreset 的定义中，首先是一个 selector。这就意味着后面这些追加的定义，只会作用于 selector 所定义的、带有“role: frontend”标签的 Pod 对象，这就可以防止“误伤”。
然后，我们定义了一组 Pod 的 Spec 里的标准字段，以及对应的值。比如，env 里定义了 DB_PORT 这个环境变量，volumeMounts 定义了容器 Volume 的挂载目录，volumes 定义了一个 emptyDir 的 Volume。
接下来，我们假定运维人员先创建了这个 PodPreset，然后开发人员才创建 Pod：
$ kubectl create -f preset.yaml
$ kubectl create -f pod.yaml
这时，Pod 运行起来之后，我们查看一下这个 Pod 的 API 对象：
$ kubectl get pod website -o yaml
apiVersion: v1
kind: Pod
metadata:
name: website
labels:
app: website
role: frontend
annotations:
podpreset.admission.kubernetes.io/podpreset-allow-database: "resource version"
spec:
containers:
- name: website
image: nginx
volumeMounts:
- mountPath: /cache
name: cache-volume
ports:
- containerPort: 80
env:
- name: DB_PORT
value: "6379"
volumes:
- name: cache-volume
emptyDir: {}
需要说明的是，PodPreset 里定义的内容，只会在 Pod API 对象被创建之前追加在这个对象本身上，而不会影响任何 Pod 的控制器的定义。
比如，我们现在提交的是一个 nginx-deployment，那么这个 Deployment 对象本身是永远不会被 PodPreset 改变的，被修改的只是这个 Deployment 创建出来的所有 Pod。这一点请务必区分清楚。
这里有一个问题：如果你定义了同时作用于一个 Pod 对象的多个 PodPreset，会发生什么呢？
实际上，Kubernetes 项目会帮你合并（Merge）这两个 PodPreset 要做的修改。而如果它们要做的修改有冲突的话，这些冲突字段就不会被修改。
K8S网络
腾讯云容器网络 vpc 对比 vxlan 性能测试
https://cloud.tencent.com/developer/article/1006675
调度
亲和度设置
高级调度nodeSelector、nodeaffinity；podaffinity、podantiaffinity
软亲和和硬亲和
preferredDuringSchedulingIgnoredDuringExecution，软亲和
通过在服务的deployment上配置反亲和性，让服务的pod尽量不要调度到同一个Node上，间接达到pod较为均匀分布在多个Node上的效果，也可以降低Node故障时对服务的影响。
requiredDuringSchedulingIgnoredDuringExecution，硬亲和
也可以配置成严格模式，要求每个Node上最多只能有一个Pod，但这样配置在启动的pod数多于Node数时会因可用Node不足起不来
容器健康检查和恢复机制
健康检查示例
在 Kubernetes 中，你可以为 Pod 里的容器定义一个健康检查“探针”（Probe）。这样，kubelet 就会根据这个 Probe 的返回值决定这个容器的状态，而不是直接以容器进行是否运行（来自 Docker 返回的信息）作为依据。这种机制，是生产环境中保证应用健康存活的重要手段。
另外Deployment、Statefulset的restartPolicy也必须为Always，保证pod异常退出，或者健康检查 livenessProbe失败后由kubelet重启容器。https://kubernetes.io/zh/docs/concepts/workloads/controllers/deployment
Job和CronJob是运行一次的pod，restartPolicy只能为OnFailure或Never，确保容器执行完成后不再重启。
这也正是 Deployment 只允许容器的 restartPolicy=Always 的主要原因：只有在容器能保证自己始终是 Running 状态的前提下，ReplicaSet 调整 Pod 的个数才有意义。
apiVersion: v1
kind: Pod
metadata:
labels:
test: liveness
name: test-liveness-exec
spec:
containers:
- name: liveness
image: busybox
args:
- /bin/sh
- -c
- touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
livenessProbe:
exec:
command:
- cat
- /tmp/healthy
initialDelaySeconds: 5
periodSeconds: 5
在这个 Pod 中，我们定义了一个有趣的容器。它在启动之后做的第一件事，就是在 /tmp 目录下创建了一个 healthy 文件，以此作为自己已经正常运行的标志。而 30 s 过后，它会把这个文件删除掉。
与此同时，我们定义了一个这样的 livenessProbe（健康检查）。它的类型是 exec，这意味着，它会在容器启动后，在容器里面执行一条我们指定的命令，比如：“cat /tmp/healthy”。这时，如果这个文件存在，这条命令的返回值就是 0，Pod 就会认为这个容器不仅已经启动，而且是健康的。这个健康检查，在容器启动 5 s 后开始执行（initialDelaySeconds: 5），每 5 s 执行一次（periodSeconds: 5）。
$ kubectl create -f test-liveness-exec.yaml
然后，查看这个 Pod 的状态：
$ kubectl get pod
NAME READY STATUS RESTARTS AGE
test-liveness-exec 1/1 Running 0 10s
可以看到，由于已经通过了健康检查，这个 Pod 就进入了 Running 状态。而 30 s 之后，我们再查看一下 Pod 的 Events：
$ kubectl describe pod test-liveness-exec
你会发现，这个 Pod 在 Events 报告了一个异常：
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
2s 2s 1 {kubelet worker0} spec.containers{liveness} Warning Unhealthy Liveness probe failed: cat: can't open '/tmp/healthy': No such file or directory
显然，这个健康检查探查到 /tmp/healthy 已经不存在了，所以它报告容器是不健康的。那么接下来会发生什么呢？我们不妨再次查看一下这个 Pod 的状态：
$ kubectl get pod test-liveness-exec
NAME READY STATUS RESTARTS AGE
liveness-exec 1/1 Running 1 1m
这时我们发现，Pod 并没有进入 Failed 状态，而是保持了 Running 状态。这是为什么呢？其实，如果你注意到 RESTARTS 字段从 0 到 1 的变化，就明白原因了：这个异常的容器已经被 Kubernetes 重启了。在这个过程中，Pod 保持 Running 状态不变。需要注意的是：Kubernetes 中并没有 Docker 的 Stop 语义。所以虽然是 Restart（重启），但实际却是重新创建了容器。这个功能就是 Kubernetes 里的 Pod 恢复机制，也叫 restartPolicy。它是 Pod 的 Spec 部分的一个标准字段（pod.spec.restartPolicy），默认值是 Always，即：任何时候这个容器发生了异常，它一定会被重新创建。
健康检查本质
值得一提的是，Kubernetes 的官方文档，把 restartPolicy 和 Pod 里容器的状态，以及 Pod 状态的对应关系，总结了非常复杂的一大堆情况。实际上，你根本不需要死记硬背这些对应关系，只要记住如下两个基本的设计原理即可：
1、只要 Pod 的 restartPolicy 指定的策略允许重启异常的容器（比如：Always），那么这个 Pod 就会保持 Running 状态，并进行容器重启。否则，Pod 就会进入 Failed 状态 。
2、对于包含多个容器的 Pod，只有它里面所有的容器都进入异常状态后，Pod 才会进入 Failed 状态。在此之前，Pod 都是 Running 状态。此时，Pod 的 READY 字段会显示正常容器的个数，比如：
所以，假如一个 Pod 里只有一个容器，然后这个容器异常退出了。那么，只有当 restartPolicy=Never 时，这个 Pod 才会进入 Failed 状态。而其他情况下，由于 Kubernetes 都可以重启这个容器，所以 Pod 的状态保持 Running 不变。
而如果这个 Pod 有多个容器，仅有一个容器异常退出，它就始终保持 Running 状态，哪怕即使 restartPolicy=Never。只有当所有容器也异常退出之后，这个 Pod 才会进入 Failed 状态。
基础操作
解决kubectl自动补全问题
[root@master ~]# yum install -y bash-completion [root@master ~]# locate bash_completion /usr/share/bash-completion/bash_completion [root@master ~]# source /usr/share/bash-completion/bash_completion
[root@master ~]# source <(kubectl completion bash)
kubectl常用命令
增：run、expose、create
删：delete
改：edit、apply、replace、patch、set
查：get、describe、explain
集群节点管理：cordon、uncordon、drain
部署管理：rollout、scale、autoscale
容器操作：logs、attach、exec、cp、port-forward
kubectl run busybox --image=busybox -it /bin/sh
attach只有在容器也有bash进程才能进入交互
exec在容器不是bash进程时也能进入交互
kubectl scale
kubectl scale --current-replicas=1 --replicas=3 deployment/nginx
kubectl autoscale
kubectl autoscale deployment nginx --min=4 --max=6
运行一个Nginx副本
kubectl run nginx --image='nginx:latest' --image-pull-policy='IfNotPresent' --replicas=1 --port=9000
kubectl attach
用于取得pod 中容器的实时信息，可以持续不断实时的取出消息。像tail -f /var/log/messages 动态查看日志的作用**
kubectl logs 是一次取出所有消息，像cat /etc/passwd
kubectl edit 修改服务端口
[root@master ~]# kubectl edit service nginx
service “nginx” edited
[root@master ~]# kubectl get service #改完端口立马生效
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes 10.254.0.1 443/TCP 17h
nginx 10.254.108.59 80:31002/TCP 25m
lable标签操作
查看pod标签信息
[root@VM_8_17_centos ~]# kubectl get pod --show-labels
NAME READY STATUS RESTARTS AGE LABELS
my-nginx 1/1 Running 0 75m env=test
my-nginx1 1/1 Running 0 35m env=pro,tier=front
my-nginx2 1/1 Running 0 43m env=test,tier=front
my-nginx3 1/1 Running 0 35m env=test
下⾯我们尝试过过滤front
[root@VM_8_17_centos ~]# kubectl get pod --show-labels -l tier=front
NAME READY STATUS RESTARTS AGE LABELS
my-nginx1 1/1 Running 0 52s env=test,tier=front
my-nginx2 1/1 Running 0 9m5s env=test,tier=front
我们把其中⼀个Pod作为更新为线上环境。
[root@VM_8_17_centos ~]# kubectl label pod my-nginx1 env=pro --overwrite
pod/my-nginx1 labeled
[root@VM_8_17_centos ~]# kubectl get pod --show-labels
NAME READY STATUS RESTARTS AGE LABELS
my-nginx 1/1 Running 0 48m env=test
my-nginx1 1/1 Running 0 8m24s env=pro,tier=front
my-nginx2 1/1 Running 0 16m env=test,tier=front
my-nginx3 1/1 Running 0 8m23s env=test,tier=backend
导出yaml文件
kubectl get deploy,sts,svc,configmap,secret app-name -o yaml --export > default.yaml
通过json格式查看服务信息
[root@master ~]# kubectl get service hostnames -o json
污点
污点设置
1、查看污点
kubectl describe nodes nodename |grep Taints
2、设置污点
kubectl taint node node名 key=value:污点三个可选值
NoSchedule : 一定不被调度
PreferNoSchedule ： 尽量不被调度
NoExecute : 不会调度，并且还会驱逐Node已有Pod
例如：kubectl taint node nodename key=value:NoSchedule
3、删除污点
kubectl taint nodes nodename key:NoSchedule-
4、添加配置文件yaml
spec:
spec:
tolerations: #容忍
- key: key #这个是设置污点的key
value: value #这个是设置污点的values
effect: NoSchedule #这个是污点类型
对于tolerations属性的写法：
其中的key、value、effect 与Node的Taint设置需保持一致， 还有以下几点说明：
1、如果operator的值是Exists，则value属性可省略。
2、如果operator的值是Equal，则表示其key与value之间的关系是equal(等于)。
3、如果不指定operator属性，则默认值为Equal。
另外，还有两个特殊值：
1、空的key 如果再配合Exists 就能匹配所有的key与value ，也是是能容忍所有node的所有Taints。
2、空的effect 匹配所有的effect。
滚动更新
控制字段
maxUnavailable: [0%, 100%] 向下取整，比如10个副本，5%的话==0.5个，但计算按照0个；
maxSurge: [0%, 100%] 向上取整，比如10个副本，5%的话==0.5个，但计算按照1个；
平滑发布建议配置
maxUnavailable == 0
maxSurge == 1
这是我们生产环境提供给用户的默认配置。即“一上一下，先上后下”最平滑原则：1个新版本pod ready（结合readiness）后，才销毁旧版本pod。****此配置适用场景是平滑更新、保证服务平稳，但也有缺点，就是“太慢”了。
快速发布建议配置
如果期望副本数是10，期望能有至少80%数量的副本能稳定工作，所以:maxUnavailable = 2，maxSurge = 2 (可自定义，建议与maxUnavailable保持一致)
发布示例
maxUnavailable = 1
maxSurge = 1
可以看到是先删除一个旧版本，待新版本创建并且running再删除一个旧版本。
汇总滚动更新命令
创建一个app：
kubectl create deployment nginx --image=nginx:1.11
创建service
kubectl expose deployment nginx --port=80 --type=NodePort
扩缩容：
kubectl scale deployment nginx --replicas=5
修改镜像，滚动更新：
kubectl set image deployment nginx nginx=nginx:1.10
或者
kubectl edit deployment/nginx
查看更新状态：
kubectl rollout status deployment nginx
终止升级
kubectl rollout pause deployment/nginx
继续升级
kubectl rollout resume deployment/nginx
回滚
kubectl rollout undo deployment/nginx
回滚到指定版本
kubectl rollout undo deployment/nginx --to-revision=2
查看滚动版本：
kubectl rollout history deployment nginx
查看信息：
kubectl describe deployment/nginx
Kubernetes 零宕机滚动更新
https://www.qikqiak.com/post/zero-downtime-rolling-update-k8s/
https://cloud.tencent.com/developer/article/1587653
集群信息
查看所有API接口
可通过 kubectl api-versions 和 kubectl api-resources 查询 Kubernetes API 支持的 API 版本以及资源对象。
查看命名空间
kubectl get --raw /api/v1/namespaces
Rancher
搭建高可用Rancher
https://www.jianshu.com/p/a628b36f330e?utm_campaign=maleskine&utm_content=note&utm_medium=seo_notes&utm_source=recommendation
新增filebeat
复制一份模板配置
修改配置
修改coding中的filebeats-cm.yaml配置的kafka的IP地址
启动filebeat
kubectl create -f filebeats-cm.yaml
kubectl create -f filebeats-rbac.yaml
kubectl create -f filebeats-daemonset.yaml
问题处理
跨节点不能互通
要清除iptables规则，这个是最新遇到的坑，什么检查都对，但是ping就是不通，使用如下命令执行删除防火墙规则，注意不是关闭防火墙就万事大吉哦，我以前也这么想的，不清除防火墙规则关闭是没用的，因为Kubernetes依赖iptables所以是不会被关闭的。
执行以下命令清除iptables规则，只在node上操作即可（其实前面两个命令就已经实现了连通性）
[root@node2 ~]# iptables -P INPUT ACCEPT
[root@node2 ~]# iptables -P FORWARD ACCEPT #其实就这两句
[root@master ~]# cat /proc/sys/net/ipv4/ip_forward #其实就这两句
不能拷贝
通过kubectl cp拷贝Pod中的文件到本地
[root@master ~]# kubectl cp mysql-2261771434-03jct:/etc/hosts /tmp/hosts
error: unexpected EOF #意外的终止了
#排错方法
[root@master ~]# kubectl cp --help
# Requires that the 'tar' binary is present in your container #想要使用kubectl cp你的容器实例中必须有tar 库
# image. If 'tar' is not present, 'kubectl cp' will fail. #如果镜像中tar命令不存在，那么拷贝会失败
#安装mysql pod中的tar命令
[root@node2 ~]# docker exec -it 2f4b76876793 /bin/bash #node2中进入到MySQL容器
bash-4.2# yum -y install tar #安装好后就可以完成以上拷贝任务
[root@master ~]# kubectl cp mysql-2261771434-03jct:/etc/hosts /tmp/hosts
#注：拷贝是双向的，可以拷贝出来，也可以拷贝进去替换掉