K8S知识点总结
Posted
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了K8S知识点总结相关的知识，希望对你有一定的参考价值。
一. 组件说明
master包含组件:
1. API SERVER: 所有服务访问统一入口
2. CrontrollerManager：维持pod副本期望数目
3. Scheduler：负责接收任务，选择合适的节点进行分配任务(pod)
4. ETCD：键值对数据库，储存k8s集群所有重要信息（持久化）
node包含组件:
5. Kubelet：直接跟容器引擎交互实现容器的生命周期管理。
6. Kube-Proxy：负责写入规则至IPTABLES、IPVS 实现服务映射访问。
其他：
7. COREDNS：可以为集群中的SVC创建一个域名与IP的对应关系解析
8. DASHBOARD：给k8s集群提供一个B/S结构访问体系
9. INGRESS CONTROLLER: 官方只能实现4层代理，INGRESS可以实现七层代理
10. FEDERATION: 提供一个可以跨集群中心的多k8s统一管理功能
11. PROMETHEUS: 提供一个k8s集群的监控能力
12. ELK：提供k8s集群日志统一分析接入平台
杂记：
查看容器运行情况：
pod运行在哪个节点，就在哪个节点查看 --> docker ps
13. pod说明：
只要运行pod，就会运行一个名为pause的容器
同一个pod内，多个容器共用pause容器的网络站，共用存储，容器间端口不能重复
14. 控制器
RC（replication controller）：确保容器应用副本数始终保持在用户定义数量。--已淘汰
RS（replica set）：跟RC功能一样，但支持集合式的selector,不支持滚动更新
Deployment支持滚动更新，但不负责pod创建，pod由RS创建；创建deployment控制器之后，会由deployment定义一个RS
15. HPA 水平自动扩展：自动增加或删除pod
16. kubectl命令自动补全：source <(kubectl completion bash)
--------------------------------------------------------------------------------
二. 安装前环境准备(master和node)
#关闭防火墙
systemctl stop firewalld
systemctl disable firewalld
#关闭selinux
sed -ri s/^SELINUX=.*/SELINUX=disabled/ /etc/selinux/config
cat /etc/selinux/config
setenforce 0
getenforce
#关闭swapoff
sed -ri s/.*swap.*/#&/ /etc/fstab #其中&代表前面匹配到的字符
cat /etc/fstab
swapoff -a
#添加hosts解析
cat /etc/hosts
cat >> /etc/hosts << EOF
192.168.80.105 k8smaster
192.168.80.106 k8snode
EOF
#config配置
cat > /etc/sysctl.d/kubernetes.conf << EOF
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
net.ipv6.conf.all.disable_ipv6 = 1
EOF
#启用config配置文件
sysctl -p /etc/sysctl.d/kubernetes.conf
#docker安装（安装前确认yum源已ok）
yum install -y docker-ce docker-ce-cli containerd.io --master和node节点都安装
--------------------------------------------------------------------------------
三. 安装
1. aliyun配置网站：https://developer.aliyun.com/mirror/kubernetes?spm=a2c6h.13651102.0.0.3e221b11wKGGFp
2. 配置kubelet/kubeadm/kubectl的yum源：
2.1 cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64/
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg https://mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-key.gpg
EOF
3. setenforce 0
4. yum install -y kubelet kubeadm kubectl
kubeadm config images list #可以列出安装所需的镜像列表
kubeadm config images pull #拉取镜像到本地
5. systemctl enable kubelet && systemctl start kubelet
ps: 由于官网未开放同步方式, 可能会有索引gpg检查失败的情况, 这时请用 yum install -y --nogpgcheck kubelet kubeadm kubectl 安装
6. yum list installed | grep kube --查询是否已安装kubeadm，kubelet，kubectl及其版本
kubeadm init phase preflight #安装前环境预检查
7. 部署kubernetes master节点
新版可直接执行：kubeadm init
kubeadm init --apiserver-advertise-address=192.168.80.105 --image-repository registry.aliyuncs.com/google_containers \\
--kubernetes-version v1.22.3 --service-cidr=10.96.0.0/12 --pod-network-cidr=10.244.0.0/16
warning:
[preflight] Running pre-flight checks
[WARNING IsDockerSystemdCheck]: detected "cgroupfs" as the Docker cgroup driver. The recommended driver is "systemd". Please follow the guide at https://kubernetes.io/docs/setup/cri/
[WARNING FileExisting-tc]: tc not found in system path
[WARNING Service-Kubelet]: kubelet service is not enabled, please run systemctl enable kubelet.service
错误关键信息总结：
Kubernetes version: v1.21.1，依赖/coredns/coredns:v1.8.0，registry.cn-hangzhou.aliyuncs.com/google_containers/coredns/coredns:v1.8.0 不存在。
解决方案：
本地执行以下命令：
docker pull coredns/coredns:1.8.0 --手动下载镜像
docker tag coredns/coredns:1.8.0 registry.cn-hangzhou.aliyuncs.com/google_containers/coredns/coredns:v1.8.0 -tag重命名
8. master安装完后提示信息：
Your Kubernetes control-plane has initialized successfully!
To start using your cluster, you need to run the following as a regular user:
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
Alternatively, if you are the root user, you can run:
export KUBECONFIG=/etc/kubernetes/admin.conf
You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
https://kubernetes.io/docs/concepts/cluster-administration/addons/
Then you can join any number of worker nodes by running the following on each as root:
kubeadm join 192.168.80.105:6443 --token u9356z.69lt89edxc7bpnq6 \\
--discovery-token-ca-cert-hash sha256:6d4393386156f7c657f57845a1ecb40beb8aebbf1f0e745a162404e4c71ec18a
如果忘记token，执行如下命令打印
kubeadm token create --print-join-command
9. 网络配置
github官网查看：https://github.com/flannel-io/flannel
curl -o ./kube-flannel.yml https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
或wget https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
kubectl apply -f kube-flannel.yml
10. 注意：
node节点需下载proxy，flannel，pause镜像，避免对应容器无法开启
11. 阿里云镜像仓库地址
registry.aliyuncs.com/google_containers/
--------------------------------------------------------------------------------
四. 命令说明
kubectl --help
1. kubectl get pod/pods --查pod
2. kubectl get deployment --查控制器
3. kubectl get service --查看服务
4. kubectl get nodes --查看节点
5. kubectl delete deployment + 控制器名字 --删除控制器
6. kubectl delete pod + pod名字 --删除pod
7. kubectl delete service + service名字 --删除service
kubectl delete rs rs名 --删除rs
8. kubectl get namespace --查看命名空间
9. kubectl describe pods + pod名字 --查看pod详情（排错常用）
kubectl describe deployments #查看deployment控制器
10. kubectl logs -f + pods名 --查看日志（排错常用）
11. kubectl run --Create and run a particular image in a pod.
12. kubectl create & kubectl apply两个命令区别
kubectl create命令，是先删除所有现有的东西，重新根据yaml文件生成新的。所以要求yaml文件中的配置必须是完整的，较适合命令式编程使用，如rs
kubectl apply命令，根据配置文件里面列出来的内容，升级现有的。所以yaml文件的内容可以只写需要升级的属性，较适合申明式编程使用，如deployment
kubectl apply/create -f yml文件 --record #recored参数可以记录命令，可以很方便的查看每次revision的变化
13. ipvsadm -Ln
14. kubectl edit svc + service名 --修改service
kubectl edit pod + pod名 --编辑pod
15. kubectl explain pod --查看pod有哪些功能模块
kubectl explain pod.apiversion --查看具体模块
16. kubectl logs myapp-pod -c test --查看容器log，其中myapp-pod为pod名，-c指定容器名，故test为容器 （一般在一个pod中有多个容器时使用）
17. kubectl exec + pod名 -it -- /bin/sh --kubectl进入容器内部，其中 “--” 为固定格式，此为pod中只有一个容器情况下
kubectl exec + pod名 -c 容器名 -it -- /bin/sh --进入pod中的某个容器
18. kubectl scale deployment/deployment名 --replicas 3 --扩容副本数为3
kubectl scale deployment nginx-deployment --replicas 4 --扩容副本数为4，其中nginx-deploymnet为deployment名称
kubectl autoscale deployment nginx-deployment --min=10 --max=15 --cpu-percent=80 #如果集群支持HPA，可设置自动扩展，cpu高于80%时扩容至15个，小于时缩减至10个pod
19. kubectl get pod -o wide --查看pod
20. kubectl get pod -n + 命名空间 --查看某个命名空间中的容器，命名空间：default/kube-node-lease/kube-public/kube-system
21. kubectl get pod --show-labels --查看pod标签
kubectl label pod pod名 tier=标签名 --修改pod标签
kubectl get endpoints
22.
k8s很多副本监控数是以标签为准
23. kubectl set image deployment/nginx-deployment nginx=nginx:v2
更新镜像，会创建一个新rs，旧rs也将保留
24. kubectl rollout undo deployment/nginx-deployment -- 回滚，回退至上一个镜像版本或rs，其中nginx-deployment为deployment控制器名称
kubectl rollout undo deployment/nginx-deployment --to-revision=2 #回滚至指定版本，此处为2版
kubetcl rollout status deployments nginx-deployment --查看回滚更新状态
kubectl rollout history deployment/nginx-deploment --查看回滚更新历史版本
kubectl rollout pause deployment/nginx-deployment #暂停deployment的更新
25. kubectl get cm +configmap名 --查看configmap
26. kubectl get pvc
kubectl get pv
kubectl get statefulset
kubectl get pv nfspv1 -o yaml #以yaml格式输出pv详细信息
kubectl edit pv nfspv1 #编辑pv
27. kubectl get node --show-labels --查看node节点标签
28. kubectl taint nodes k8snode01 checker=app:NoExecute #设置taint污点标签
kubectl taint nodes k8snode01 checker=app:NoExecute- #删除taint污点，末尾的“-”表示删除
29. dig nginx-nfs.default.svc.cluster.local @10.244.0.8 --statefulset使用headless服务来控制pod的域名，此为域名的FQDN
service名 namespace名 .svc.clusterlocal为固定格式 @DNSIP
clusterlocal为集群域名
30. kubectl api-resources #查看权限列表
--------------------------------------------------------------------------------
五. Label说明
Label Selector的表达式有两种：基于等式的（Equality-based）和基于集合的（Set-based）。
下面是基于等式的匹配例子：
name=redis-slave：匹配所有标签为name=redis-slave的资源对象。
env != production：匹配所有标签env不等于production的资源对象。
下面是基于集合的匹配例子
name in (redis-master, redis-slave)：匹配所有标签为name=redis-master或者name=redis-slave的资源对象。
name not in (php-frontend)：匹配所有标签name不等于php-frontend的资源对象。
还可以通过多个Label Selector表达式的组合实现复杂的条件选择，多个表达式之间用“,”进行分隔即可，几个条件之间是“AND”的关系，即同时满足多个条件，例如：
name=redis-slave, env!=production
name not in (php-frontend), env!=production
Pod中lebel定义在metada中：
apiVersion: v1
kind: Pod
metadata:
name: myweb
labels:
app: myweb
RC和Service在spec中定义Selector与Pod进行关联：
RC:
apiVersion: v1
kind: ReplicationController
metadata:
name: myweb
spec:
replicas: 1
selector:
app: myweb
template:
…………
Service：
apiVersion: v1
kind: Service
metadata:
name: Test
spec:
type: NodePort
selector:
app: myweb
ports:
- port: 80
nodePort: 30008
targetPort: 80
protocol: TCP
Deployment、ReplicaSet、DaemonSet和Job则可以在Selector中使用基于集合的筛选条件：
selector:
matchLabels:
app: myweb
matchExpressions:
- key: tier, operator: In, values: [frontend]
- key: environment, operator: NotIn, values: [dev]
matchLabels用于定义一组Label，与直接写在Selector中作用相同；matchExpressions用于定义一组基于集合的筛选条件，可用的条件运算符包括：In、NotIn、Exists和DoesNotExist。
如果同时设置了matchLabels和matchExpressions，则两组条件为“AND”关系，即所有条件需要同时满足才能完成Selector的筛选
--------------------------------------------------------------------------------
六. Replica Set
Replica Set支持基于集合的Label selector（Set-based selector），而RC只支持基于等式的Label selector（equality-based selector），所以Replica Set的功能更强大。
RS例子：
apiVersion: extensions/v1beta1
kind: ReplicaSet
metadata:
name: frontend
spec:
selector:
matchLabels:
tier: frontend
matchExpressions:
- key: tier, operator: In, values: [frontend]
template:
…………
Replica Set很少单独使用，它主要被Deployment这个更高层的资源对象所使用，从而形成一整套Pod创建、删除、更新的编排机制。
RC和RS的特性与作用如下：
-在大多情况下，我们通过定义一个RC实现Pod的创建过程及副本数量的自动控制。
-RC里包括完整的Pod定义模板。
-RC通过Label Selector机制实现对Pod副本的自动控制。
-通过改变RC里的Pod副本数量，可以实现Pod的扩容或缩容功能。
-通过改变RC里Pod模板中的镜像版本，可以实现Pod的滚动升级功能。
--------------------------------------------------------------------------------
七. Deployment
Deployment相对于RC的最大区别是我们可以随时知道当前Pod“部署”的进度。
创建一个Deployment对象来生成对应的Replica Set并完成Pod副本的创建过程。
定义例子：
apiVersion: apps/v1
kind: Deployment
metadata:
name: frontend
spec:
replicas: 1
selector:
matchLabels:
tier: frontend
matchExpressions:
- key: tier, operator: In, values: [frontend]
template:
metadata:
labels:
app: app-demo
tier: frontend
spec:
containers:
- name: tomcat-demo
image: tomcat
imagePullPolicy: IfNotPresent
ports:
- containerPort: 8080
可以通过命令kubectl get deployment来查看Deployment的信息，其中的几个参数解释如下：
> DESIRED:：Pod副本数量的期望值，即Deployment里定义的Replica。
> CURRENT：当前Replica的值，如果小于DESIRED的期望值，会创建新的Pod，直到达成DESIRED为止。
> UP-TO-DATE：最新版本的Pod的副本数量，用于指示在滚动升级的过程中，有多少个Pod副本已经成功升级。
> AVAILABLE：当前集群中可用的Pod副本数量，即集群中当前存活的Pod数量。
--------------------------------------------------------------------------------
八. service
1. 客户端访问pod流程(iptables代理版，目前由ipvs替代)：
* 监听服务和端点由apiserver完成，通过kube-proxy监控；kube-proxy负责监控对应到的pod，及其匹配到的信息，并写入到iptables规则中。
* 客户端访问svc时，其实是访问的iptables规则，导向到后端pod对应的地址信息。
* 客户端访问pod是通过iptables实现的，iptables的规则是通过kube-proxy写入。
* apiserver通过监控kube-proxy以发现services和endpoints
* kube-proxy通过pod的labels（标签）信息判断此pod是否已写入到svc的端点信息里面
2. 一组pod可以对应到多个svc
3. 定义service
apiVersion: v1 #创建该对象所使用kubernetes api版本
kind: Service #创建对象的类别
metadata: #唯一性标识对象的一些数据
name: showdoc #service名称，同一个namespace中必须唯一
namespace: default #service所在命名空间
labels: #service的label
app: showdoc
sepc:
type: NodePort #service暴露端口类型，一般有clusterIP/NodePort/LoadBalance
ports:
- port: 80 #service的端口
targetPort: 80 #目标端口，containerPort：80
selector: #定义标签选择器，本例匹配statefulset的labels
app: showdoc
三个端口(port/nodeport/targetport)说明：
port和nodePort都是service的端口，前者暴露给集群内客户访问服务，后者暴露给集群外客户访问服务。
从这两个端口到来的数据都需要经过反向代理kube-proxy流入后端pod的targetPort，从而到达pod上的容器内。
4. ingress
官网：https://kubernetes.github.io/ingress-nginx/
定义ingress：
apiVersion: apps/v1 #该对象所使用的kubernetes api版本
kind: Ingress #创建对象的类别
metadata:
name: showdoc #该对象名称
namespace: default #该对象所属命名空间
annotations: #注解
kubernetes.io/ingress.class: nginx #声明使用的ingress控制器
spec:
rules:
- hosts: showdoc.example.com #服务的域名
http:
paths:
- path: / #路由路径
backend: #后端service
serviceName: showdoc #对应service的名称
servicePort: 80 #对应service的端口
--------------------------------------------------------------------------------
九. Volume(存储卷)
1.emptyDir
emptyDir是在Pod分配到Node时创建的，它的初始内容为空，并且无须指定宿主机上对应的目录文件，它是Kubernetes自动分配的一个目录，当Pod从Node上移除时，emptyDir中的数据也会被永久删除。
emptyDir的用途如下：
> 临时空间，例如用于某些应用程序运行时所需的临时目录，且无须永久保存。
> 长时间任务的中间过程CheckPoint的临时保存目录。
> 一个容器需要从另一个容器中获取数据的目录（多容器共享目录）,同一个Pod中共享。
定义举例：
template:
metadata:
labels:
app: app-demo
tier: frontend
spec:
volumes:
- name: datavol
emptyDir:
containers:
- name: tomcat-demo
image: tomcat
imagePullPolicy: IfNotPresent
volumeMounts:
- mountPath: /mydata-data
name: datavol
2. hostPath
使用hostPath挂载宿主机上的文件或目录，主要用于以下几个方面：
> 容器应用程序生成的日志文件需要永久保存时，可以使用宿主机的文件系统存储。
> 需要访问宿主机上Docker引擎内部数据时，可以定义hostPath的宿主机目录为docker的数据存储目录，使容器内部应用可以直接访问docker的数据文件。
使用hostPath时，需要注意以下几点：
> 在不同的Node上的Pod挂载的是本地宿主机的目录，如果要想让不同的Node挂载相同的目录，则可以使用网络存储或分布式文件存储。
> 如果使用了资源配额管理，则Kubernetes无法将其在宿主机上使用的资源纳入管理。
hostPath的定义如下：
volumes:
- name: "persistent-storage"
hostPath:
path: "/data"
3.gcePersistentDisk
使用这种类型的Volume表示使用谷歌公有云提供的永久磁盘（Persistent Disk，PD）存放数据，
使用gcePersistentDisk有以下一些限制条件：
> Node需要是谷歌GCE云主机。
> 这些云主机需要与PD存在于相同的GCE项目和Zone中。
通过gcloud命令创建一个PD：
gcloud compute disks create --size=500GB --zone=us-centrall-a my-data-disk
定义gcePersistentDisk类型的Volume的示例如下：
volumes:
- name: test-volume
gcPersistentDisk:
pdName: my-data-disk
fsType: ext4
4.awsElasticBlockStore
与GCE类似，该类型的Volume使用亚马逊公有云提供的EBS Volume存储数据，需要先创建一个EBS Volume才能使用awsElasticBlockStore。
使用awsElasticBlockStore的一些限制条件如下：
> Node需要是AWS EC2实例。
> 这些AWS EC2实例需要与EBS volume存在于相同的region和availability-zone中。
> EBS只支持单个EC2实例mount一个volume。
通过aws ec2 create-volume命令创建一个EBS volume：
aws ec2 create-volume --availability-zone eu-west-la --size 10 --volume-type gp2
定义awsElasticBlockStore类型的Volume的示例如下：
volumes:
- name: test-volume
awsElasticBlockStore:
volumeID: aws://<availability-zone>/<volume-id>
fsType: ext4
5.NFS
使用NFS网络文件系统提供的共享目录存储数据时，我们需要在系统中部署一个NFS Server。
定义NFS类型的Volume的示例如下：
volumes:
- name: nfs-volume
nfs:
server: nfs-server.localhost
path: "/"
6.其他类型的Volume
iscsi：使用iSCSI存储设备上的目录挂载到Pod中。
flocker：使用Flocker来管理存储卷。
glusterfs：使用GlusterFS网络文件系统的目录挂载到Pod中。
rbd：使用Ceph块设备共享存储（Rados Block Device）挂载到Pod中。
gitRepo：通过挂载一个空目录，并从GIT库clone一个git repository以供Pod使用。
secret：一个secret volume用于为Pod提供加密的信息，可以将定义在Kubernetes中的secret直接挂载为文件让Pod访问。Secret volume是通过tmfs（内存文件系统）实现的，所以这种类型的volume不会持久化。
--------------------------------------------------------------------------------
十. PV/PVC (持久存储卷)
PV与Volume的区别如下：
> PV只能是网络存储，不属于任何Node，但可以在每个Node上访问。
> PV并不是定义在Pod上的，而是独立于Pod之外定义。
下面是NFS类型PV的yaml定义内容，声明了需要5G的存储空间：
apiVersion: v1
kind: PersistenVloume
metadata:
name: pv01
spec:
capacity:
storage: 5Gi
persistentVolumeReclaimPolicy: Recycle
accessMode:
- ReadWriteOnce
nfs:
path: /somepath
server: 192.168.80.108
PV的accessModes属性有以下类型：
> ReadWriteOnce：读写权限、并且只能被单个Node挂载。
> ReadOnlyMany：只读权限、允许被多个Node挂载。
> ReadWriteMany：读写权限、允许被多个Node挂载。
如果Pod想申请使用PV资源，则首先需要定义一个PersistentVolumeClaim（PVC）对象：
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc-01
spec:
accessMode:
- ReadWriteOnce
resources:
requests:
storage: 5Gi
然后在Pod的volume定义中引用上述PVC即可:
volumes:
- name: mypd
persistentVolumeClaim:
claimName: pvc-01
PV是有状态的对象，它有以下几种状态：
> Available：空闲状态。
> Bound：已经绑定到某个PVC上。
> Released：对应的PVC已经删除，但资源还没有被集群收回。
> Failed：PV自动回收失败。
--------------------------------------------------------------------------------
十一. HPA
HPA有以下两种方式作为Pod负载的度量指标：
> CPUUtilizationPercentage
> 应用程序自定义的度量指标，比如服务在每秒内的相应的请求数（TPS或QPS）
CPUUtilizationPercentage是一个算术平均值，即目标Pod所有副本自带的CPU利用率的平均值。一个Pod自身的CPU利用率是该Pod当前CPU的使用量除以它的Pod Request的值，
比如我们定义一个Pod的Pod Request为0.4，而当前Pod的CPU使用量为0.2，则它的CPU使用率为50%，
HPA定义举例:
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
name: php-apache
namespace: default
spec:
maxReplicas: 10
minReplicas: 2
scaleTargetRef:
kind: Deployment
name: php-apache
targetCPUUtilizationPercentage: 90
除了通过yaml文件来定义HPA对象之外，还可以通过命令的方式创建：
kubectl autoscale deployment php-apache --namespace kube-example --cpu-percent=90 --min=1 --max=10
--------------------------------------------------------------------------------
十二. StatefulSet
StatefulSet有如下一些特性：
> StatefulSet里的每个Pod都有稳定、唯一的网络标识，可以用来发现集群内的其他成员。假设StatefulSet的名字叫kafka，那么第1个Pod叫kafka-0，第2个叫kafka-1，以此类推。
> StatefulSet控制的Pod副本的启停顺序是受控的，操作第n个Pod时，前n-1个Pod已经是运行且准备好的状态。
> StatefulSet里的Pod采用稳定的持久化存储卷，通过PV/PVC来实现，删除Pod时默认不会删除与StatefulSet相关的存储卷（为了保证数据的安全）。
StatefulSet除了要与PV卷捆绑使用以存储Pod的状态数据，还要与Headless Service配合使用，即在每个StatefulSet的定义中要声明它属于哪个Headless Service,
Headless Service与普通Service的区别在于，它没有Cluster IP，如果解析Headless Service的DNS域名，则返回的是该Service对应的全部Pod的Endpoint列表。
StatefulSet在Headless Service的基础上又为StatefulSet控制的每个Pod实例创建了一个DNS域名，这个域名的格式为：
$(podname).$(headless service name)
比如一个3节点的kafka的StatefulSet集群，对应的Headless Service的名字为kafka，StatefulSet的名字为kafka，
则StatefulSet里面的3个Pod的DNS名称分别为kafka-0.kafka、kafka-1.kafka、kafka-3.kafka，
定义举例：
#定义statefulset
apiVersion: apps/v1 #创建该对象所使用的kubernetes api的版本
kind: StatefulSet #想要创建对象的类别
metadata: #帮助唯一性标识对象的一些数据，包括一个name字符串、UID和可选的namespace
name: showdoc #想要创建的对象名字，同一个namespace中必须唯一
namespace: default #想要创建的对象所在的命名空间
labels: #想要创建对象的标签
app: showdoc #标签
spec: #对象规格，指定资源的内容
serviceName: showdoc #对象名称
replicas: 2 #对象副本数
selector: #便签选择器，用于匹配pod的标签
matchLabels:
app: showdoc
template: #定义pod
metadata: #pod的label
labels:
app: showdoc
spec: #指定该资源的内容
terminationGracePeriodSeconds: 180
iniContainers: #定义初始化容器
- name: init #初始化容器名称
image: busybox:v1 #指定使用image及其版本
command: ["/bin/sh","-c","chmod","777","-R","/var/www"] #启动容器运行的命令，将覆盖容器中的entrypoint，对应docker中的entrypoint
imagePullPolicy: IfNotPresent #镜像拉取策略，有三个选项：always每次都从线上拉取；never只检查本地是否有对应镜像；ifnotpresent表示如果本地有就用本地的，没有就从线上拉取
volumeMounts: #设置挂载持久卷信息
- name: volume #挂载设备的名字，要与volumeclaimtemplate中定义name一致
mountPath: /var/www/html #挂载到容器中的目录
containers: #业务容器
- name: showdoc #容器名称
image: nginx:v1 #容器使用镜像及版本
imagePullPolicy: IfNotPresent #镜像拉取策略
ports:
- containerPort: 80 #容器对外开放端口
name: port #端口名称
volumeMounts:
- name: volume #挂载持久存储卷
mountPath: /var/www/html #容器内持久存储卷挂载路径
volumeClaimTemplate: #持久化存储模板，使用存储类
- metadata: #定义唯一性标识对象的一些数据
name: volume #定义一个挂载设备的名字，为volumemounts提供name
spec:
accessModes: ["ReadWriteOnce"] #挂载存储的读写模式
storageClassName: nfs #存储的名字
resources: #存储资源
requests:
storage: 50Gi #存储资源的空间大小
--------------------------------------------------------------------------------
十三 .私有云harbor配置
1. vim /etc/docker/daemon.json添加如下命令，然后重启docker
"insecure-registries": ["http://hub.atguigu.com"] --域名需按实际harbor调整
2. 加载docker-compose
3. 加载harbor安装包
github+jenkins+harbor+docker+k8s
--------------------------------------------------------------------------------
十四. Probe(探针)
探针是由 kubelet 对容器执行的定期诊断，可执行如下三种动作进行诊断:
> Exec：在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功。
> TCPSocket：对指定端口上的容器的 IP 地址进行 TCP 检查。如果端口打开，则诊断被认为是成功的。
> HTTPGet：对指定的端口和路径上的容器的 IP 地址执行 HTTP Get 请求。如果响应的状态码大于等于200 且小于 400，则诊断被认为是成功的。
每次探测都将获得以下三种结果之一：
成功：容器通过了诊断。
失败：容器未通过诊断。
未知：诊断失败，因此不会采取任何行动。
1. readlinessProbe（就绪探针）
指示容器是否准备好服务请求。如果就绪探测失败，端点控制器将从与 Pod 匹配的所有 Service 的端点中删除该 Pod 的 IP 地址。初始延迟之前的就绪状态默认为 Failure。如果容器不提供就绪探针，则默认状态为 Success。
举例1：
readinessProbe:
httpGet:
path: /test.heml
port: 80
initialDelaySeconds: 5 #kubelet在第一次执行探针之前要等待的时间，单位为秒
periodSeconds: 5 #探针执行的频率，此处为每隔10秒执行一次
举例2：
readinessProbe:
tcpSocket:
port: 80
initialDelaySeconds: 5
periodSeconds: 5
2. livenessProbe（存活探针）
指示容器是否正在运行。如果存活探测失败，则 kubelet 会杀死容器，并且容器将受到其 重启策略 的影响。如果容器不提供存活探针，则默认状态为 Success。
举例：
livenessProbe:
exec:
command:
- cat
- /tmp/healthy
initialDelaySeconds: 5
periodSeconds: 5
3. startupProbe（启动探针）
指示容器中的应用是否已经启动。如果提供了启动探测(startup probe)，则禁用所有其他探测，直到它成功为止。如果启动探测失败，kubelet 将杀死容器，容器服从其重启策略进行重启。如果容器没有提供启动探测，则默认状态为成功Success。
--------------------------------------------------------------------------------
十五. 各种apiVersion含义
1. alpha
* 该软件可能包含错误。启用一个功能可能会导致bug
* 随时可能会丢弃对该功能的支持，恕不另行通知
2. beta
* 软件经过很好的测试。启用功能被认为是安全的。
* 默认情况下功能是开启的
* 细节可能会改变，但功能在后续版本不会被删除
3. stable
* 该版本名称命名方式：vX这里X是一个整数
* 稳定版本、放心使用
* 将出现在后续发布的软件版本中
4. v1
Kubernetes API的稳定版本，包含很多核心对象：pod、service等
5. apps/v1beta2
* 在kubernetes1.8版本中，新增加了apps/v1beta2的概念，apps/v1beta1同理
* DaemonSet，Deployment，ReplicaSet 和 StatefulSet的当时版本迁入apps/v1beta2，兼容原有的extensions/v1beta1
6. apps/v1
* 在kubernetes1.9版本中，引入apps/v1，deployment等资源从extensions/v1beta1, apps/v1beta1 和 apps/v1beta2迁入apps/v1，原来的v1beta1等被废弃。
* apps/v1代表：包含一些通用的应用层的api组合，如：Deployments, RollingUpdates, and ReplicaSets
7. batch/v1
* 代表job相关的api组合
* 在kubernetes1.8版本中，新增了batch/v1beta1，后CronJob 已经迁移到了 batch/v1beta1，然后再迁入batch/v1
8. autoscaling/v1
* 代表自动扩缩容的api组合，kubernetes1.8版本中引入。
* 这个组合中后续的alpha 和 beta版本将支持基于memory使用量、其他监控指标进行扩缩容
9. extensions/v1beta1
deployment等资源在1.6版本时放在这个版本中，后迁入到apps/v1beta2,再到apps/v1中统一管理
10. certificates.k8s.io/v1beta1
安全认证相关的api组合
11. authentication.k8s.io/v1
资源鉴权相关的api组合
----------------------------------------------------------------------------------------------------------------------------------------------------------------
CPU说明：
1cpu为1核心cpu
1cpu=1000m cpu
表达式 0.1 CPU 等价于表达式 100m cpu，可以看作 “100 millicpu”
在metrics-server中，获取某个节点的使用情况，cpu的单位有时是n (1m = 1000*1000n )
----------------------------------------------------------------------------------------------------------------------------------------------------------------
十六. Node隔离命令
隔离：
法一：kubectl patch node k8snode01 -p "spec":"unschedulable":true
法二：kubectl cordon k8snode01
解除隔离：
法一：kubectl patch node k8snode01 -p "spec":"unschedulable":false
法二：kubectl uncordn k8snode01
--------------------------------------------------------------------------------
十七. 服务质量 QoS
QoS 主要分为 Guaranteed、Burstable 和 Best-Effort三类，优先级从高到低.
1. Guaranteed(有保证的)
属于该级别的 Pod 有以下两种：
Pod 中的所有容器都且仅设置了 CPU 和内存的 limits
Pod 中的所有容器都设置了 CPU 和内存的 requests 和 limits ，且单个容器内的requests==limits（requests不等于0）
举例：（仅设置了 CPU 和内存的 limits）
containers:
- name: foo
resources:
limits:
cpu: 10m
memory: 1Gi
- name: bar
resources:
limits:
cpu: 100m
memory: 100Mi
举例：（单个容器内的requests==limits）
containers:
- name: foo
resources:
limits:
cpu: 10m
memory: 1Gi
requests:
cpu: 10m
memory: 1Gi
2.Burstable(不稳定的)
Pod 中只要有一个容器的 requests 和 limits 的设置不相同，那么该 Pod 的 QoS 即为 Burstable。
举例：（容器 foo 指定了 resource，而容器 bar 未指定）
containers:
- name: foo
resources:
limits:
cpu: 10m
memory: 1Gi
requests:
cpu: 10m
memory: 1Gi
- name: bar
举例：（容器 foo 设置了内存 limits，而容器 bar 设置了CPU limits）
containers:
- name: foo
resources:
limits:
memory: 1Gi
- name: bar
resources:
limits:
cpu: 100m
注意：如果容器指定了 requests 而未指定 limits，则 limits 的值等于节点资源的最大值，如果容器指定了 limits 而未指定 requests，则 requests 的值等于 limits。
3.Best-Effort(尽最大努力)
如果 Pod 中所有容器的 resources 均未设置 requests 与 limits，该 Pod 的 QoS 即为 Best-Effort
举例：
containers:
- name: foo
resources:
- name: bar
resources:
---------------------------------------------------------------------------
以上是关于K8S知识点总结的主要内容，如果未能解决你的问题，请参考以下文章