k8s合集，期末大总结，含泪肝万字。
k8s超干货，期末大总结，含泪肝万字，考试看这一篇就够了。忘多多支持。
目录
4、存活性探测livenessProbe和就绪性探测readinessProbe的区别是什么？
前言
我刚开始感觉一二三部分考的内容不多，可能第一部分就考一些命令，第二部分就考一些概念，要不然还能考什么？考搭建docker swarm集群？不可能！后边还有一堆kubernets的内容没考，在这给你考搭建？做梦，第三部分考的几率也比较小，但是有几条命令，就写了点。后来才知道根本不考，所以为了应付考试的话，可以不看哈！重点在第四部分及之后（导图里全是重点），那才是kubernets的大方向。
下面是老师给的考试的思维导图奉上
一，docker 资源配额
docker容器控制cpu
Docker是通过CGroups来实现对CPU，内存和磁盘I/O等资源的控制。
1，指定docker容器可以使用的cpu份额
例1：给容器分配512权重的cpu使用份额
docker run -it --cpu-shares 512 centos /bin/bash--cpu-share int ：CPU配额参数
例2：设置容器进程需要每秒使用单个CPU的0.2s时间
docker run -dit --cpu-period 100000 --cpu-quota 200000 centos--cpu-period指定容器对CPU的使用多长时间重新分配一次
--cpu-quota指定在这个周期内最多可以使用的时间
CPU core 核心控制：
参数：--cpuset 可以绑定 CPU
CPU配额控制参数的混合使用
例1：指定docker1只能在CPU0和CPU1上运行，且使用份额为512
dockre run -dit --name docker1 --cpuset-cpus 0,1 --cpu-shares 512 centos /bin/bash例2：指定docker2只能在CPU0和CPU2上运行，且使用份额为1024
docker -dit --name docker2 --cpuset-cpus 0,1 --cpu-shares 1024 centos /bin/bashdocker容器控制内存
参数：--memory-swappiness：设置容器的虚拟内存控制行为
--kernel-memory：核心内存限制
--memory：设置容器使用的最大内存上限
--memory-swap：内存和swap的总和
--memory-reservation：启用弹性的内存共享
例：创建一个docker，只能使用2个核心，且只能使用128M内存。
docker run -it --cpuset-cpus 0,1 -m 128m centosdocker 容器控制IO
参数：--device-read-bps：限制设备的读速度
--device-read-iops：限制设备每秒读I/O的次数
--device-write-bps：限制设备的写速度
--device-write-iops：限制设备每秒写I/O的次数
例：限制容器实例对硬盘的最高写入速度为2MB/s。
docker run -it -v /var/www/html/:/var/www/html --device /dev/sda:/dev/sda --device-write-bps /dev/sda:2mb centos /bin/bashdocker容器运行结束自动释放资源
参数：--rm：当容器运行结束后，自动删除容器，释放资源
例：
docker run -it --rm --name c1 centos sleep概念总结：
资源配额就是可以实现容器的资源调度使用的控制，及容器的读写速度，运行在哪个CPU上。
二，docker swarm集群
1，docker swarm集群是什么
是一套管理Docker集群的工具，将一群Docker宿主机变成一个单一的，虚拟的主机
2，Docker Swarm
服务（Service）：实在工作节点所允许的一组任务的定义，是整个swarm的核心，一个service由多个任务组成
任务（Task）：是swarm中最小调度单元，任务就是一个容器，容器中运行的命令或应用。
3，Docker Swarm架构
Swarm Manager管理节点：负责swarm集群管理，并向工作节点分配工作
Swarm Node工作节点：接受并执行来自管理节点分配的任务
一个Node就是一台Docker宿主机，管理节点是领导，工作节点是小兵，但领导也会工作，小兵也可以被提拔为领导。
4，swarm特性
动态扩展服务--水平扩展
负载均衡，节点宕机，节点提权/降权
三，命名空间namespace
概念
kubernetes支持多个虚拟集群，它们底层依赖于同一个物理集群，这些虚拟集群被称为命名空间。
考什么
既然是命名空间，那就肯定是考创建，查看，删除，切换……
例1：查看有哪些命名空间
kubectl get namespace例2：查看命名空间及其资源对象
kubectl get pods -n kube-system k8s的安装组件在此例3：创建一个test命名空间
kubectl create ns test例4：切换命名空间
kubectl config set-context --current --namespace=kube-system例5：删除命名空间
kubectl delete ns test例6：查看命名空间详细信息
kubectl describe ns test还有一个点就是namespace的资源限额，这个可能就考考你yaml清单文件里的内容什么意思
例7：所有容器的内存请求总额不得超过2GiB。
所有容器的内存限额总额不得超过4 GiB。
所有容器的CPU请求总额不得超过2 CPU。
所有容器的CPU限额总额不得超过4CPU。
hard:
requests.cpu: "2"
requests.memory: 2Gi
limits.cpu: "4"
limits.memory: 4Gi
四，Pod（重头戏开始）
1，Pod是什么
Kubernets中的最小调度单元。
2，Pod
Pod中运行容器，容器中指定镜像，容器可以有多个，为避免管理复杂化，尽量采用一个容器的Pod。
3，Pod工作方式
Pod需要调度到nod工作节点中来运行，具体哪个节点看scheduler调度器。
4，PodIP
每个Pod都会有一个唯一的IP地址。
5，Pod的状态
Pending（挂起），Running（正常运行中，一般都是这个），Succeeded（成功运行完毕），Unknown（未知），Failed（失败）
6，相关命令
创建pod，删除pod，查看pod，查看pod详细信息，查看所有podIP节点信息，进入pod
kubectl apply -f filename.yaml
kubectl delete podname
kubectl get pods
kubectl describe pod podname
kubectl get pods -o wide
kubectl exec -it podname /bin/bash7，自主式Pod
一般我们都会以yaml资源清单的方式（就是文件名可以随便起，扩展名必须是.yaml）去创建，考的时候也是这么考，可能考你这个yaml文件怎么写，也可能给出你来，让你去解释每行什么意思，下面就来简单介绍一下吧！
apiVersion: v1 ##版本信息
kind: Pod ##创建的是什么类型
metadata: ##对象，定义元数据属性信息
name: Podname ##Pod的名字
namespace: default ##此Pod属于哪个命名空间
labels: ##Pod的标签
app:tomcat ##app=tomcat
spec: ##代表下面是容器的信息
containers: ##容器中会执行的命令
- name: dockername1 ##容器的名字
image: centos ##容器要用到的镜像
ports: ##端口信息
- containerPort: 8080 ##暴露8080端口
imagePullPolicy: IfNotPresent ##镜像的拉取策略，分为三种，下边会说到
- name: dockername2 ##第二个容器的信息，与第一个基本相似
image: ……
…… ……
…… ……- Always：不管镜像是否存在都会进行一次拉取。
- Never：不管镜像是否存在都不会进行拉取
- IfNotPresent：只有镜像不存在时，才会进行镜像拉取
通过上面这个文件创建出来的Pod，我们称之为自主式Pod，简单来说就是，删掉后就是删掉了，这就是他的一个缺陷，所以就会用到下边的Deployment或者Replicaset控制器的方式来管理Pod。
五，Deployment和Replicase
其实我在一篇文章中已经详细的讲过Deployment控制器了，本篇文章就不再详细说了，可以去看这篇：K8S控制器之Deployment详解及配置。_无求道贾的博客-CSDN博客，这次就来说说Deployment和replicase的区别。
首先：是Deployment包含Replicase，再一个需要注意i的地方，就是Deployment在更新回滚Pod的时候是全自动的，不需要手动去删除旧的Pod，而Replicase是不会自动删除的，它需要你手动去删除，这是他的缺陷，还有一个就是Replicase=rc=rs，基本都是一个东西。
六，Label与Label Selector
1，标签是干什么的
标签（Label）就是附在Kubernets对象（如Pod，Deployment）上的键对值（Key-Value），可以在创建时指定，也可以在创建后指定
2，个数
一个对象可以有多个标签。
3，标签的作用
其实Label的作业不仅仅是一种对象的标识，后面我们会通过特殊的标签去对应Pod等等一些服务，这才是它的关键作用。
还有一个就是更方便的管理不同的Pod，比如你有5个Pod，但你想统一管理其中3个Pod，就可以给这三个Pod打上相同的Label，从而实现更方便的批量管理。
4，相关命令
这一部分内容，除了上边的理论之外，就是如何给对象打标签的语法了，一起来看看吧！
例1：查看所有Pod的所有label。
kubectl get pods --show-labels例2：给Pod打标签，给pod打上一个time=2021的标签。
kubecal label pod podname time=2021例3：基于等值的标签选择器查，查标签为time=2021的pod，并显示其标签。
kubectl label pod -l time=2021 --show-labels例4：基于集合的标签选择器查，查标签time不是2022的，并显示其标签。
kubectl get pod -l time!=2022 --show-labels例5：还有就是再yaml资源清单中的metadata字段下来定义。
metadata:
app: nginx
time: 2021
key: value例6：除此之外还可以给node节点打标签，一般用于让这个Pod运行在这个node节点上。
kubectl label nodes nodename env=test在yaml文件中通过nodeSector字段来选择这个节点
nodeSelector:
env: test七，Service服务发现
1，什么是Kubernets中的Service
简单来说就是外界访问pod的桥梁，对外暴露服务的方式。那么问题来了，每个Pod不是有自己唯一的IP吗？我们在扩容，更新时Pod是会改变的，所以就引入了Service，通过Service去访问所对应的Pod，而它们之间就是通过相同的labels来关联的
2，Service的类型
ClusterIP：默认模式，提供一个集群内部的虚拟IP专供集群内部访问，外部无法访问。
NodePort：在所有节点上开放一个特定端口，任何发送到该端口的流量都被转发到对应服务。
Load Balancer：直接暴露服务，所有通往你指定的端口的流量都会被转发到对应的服务。它没有过滤条件，没有路由。
3，Endpoint Controller
负责维护Service和Pod IP之间的对应关系，当Service对应的Pod发生变化时，endpoints也会自动改变。
4，ClusterIP的创建
同样，Service的创建也是写yaml资源清单。
apiVersion: v1
kind: Service
metadata:
name: Servicename
spec:
selector:
app: httpd ##通过此标签自动匹配相同标签的Pod
ports:
- protocol: TCP
port: 8080 ##Service的端口，客户端通过此端口访问
targetPort: 80 ##后端Pod的端口，需与Pod提供服务的端口一致5，NodePort的创建
apiVersion: v1
kind: Service
metadata:
name: Servicename
spec:
type: NodePort ##新增加的用于指定Service类型
selector:
app: httpd ##和上一个一样用于做匹配关联
ports:
- protocol: TCP
port: 8080 ##Service的端口
targetPort: 80 ##后端容器端口
nodePord: 30144 ##访问时通过“节点IP地址：端口”6，CoreDNS
以域名的方式来访问Pod。
kubeDNS是前期版本kubernets中默认的dns组件
IPVS需要手动开启方可使用
7，Headless Service
没有IP地址的Service服务，主要用于StatefulSet（后边会讲到）
apiVersion: v1
kind: Service
metadata:
name: Servicename
spec:
selector:
app: httpd ##通过此标签自动匹配相同标签的Pod
ports:
- protocol: TCP
port: 8080 ##Service的端口，客户端通过此端口访问
targetPort: 80 ##后端Pod的端口，需与Pod提供服务的端口一致
clusterIP: None ##多出来的一条，就是为了说明此Service没有IP8，相关命令
例：应用Service，查看Service，删除Service，查看endpoint信息：
kubectl apply -f Servicefiel.yaml
kubectl get service -o wide
kubectl delete service servicename
kubectl get endpoints八，DaemonSet与Job
1，DamonSet是什么？
DaemonSet是另一种Pod控制器，不同于Deployment和rs。
2、DaemonSet和Deployment的区别是什么？
DaemonSet在每个节点都会自动生成一个pod跟随节点的变化而变化，节点存在则存在，节点消失则消失，而Deployment是始终维持副本数量。
3、Job和CronJob是什么，区别是什么？
job：一次性任务
cronjob：周期性任务，每执行依次都会生成一个一次性的pod
4，创建DaemonSet
通过yaml资源清单文件
apiVersion: apps/v1 ##版本不同
kind: DaemonSet ##类型不一样
metadata:
name: DaemonSetname
spec:
selector:
matchLabels:
app: nginx
template: ##Pod模板信息
metadata:
labels:
app: nginx
spec:
containers:
- name: dockername
image: nginx
ports:
- containerPort: 805，创建一次性任务Job
通过yaml资源清单文件
apiVersion: batch/v1 ##版本不同
kind: Job ##类型不一样
metadata:
name: Jobname
spec:
selector:
matchLabels:
app: nginx
template: ##Pod模板信息
metadata:
labels:
app: nginx
spec:
containers:
- name: dockername
image: nginx
command: ["/bin/bash","-c","-- sleep 30000"]
restartPolicy: Never ##重启策略，只能为Never或OnFailure
backoffLimit: 3 ##job失败后重启的次数在deployment，restartPolicy还可以设置为always
6，创建CronJob
通过yaml资源清单文件，Cron Job不是Job的一种，属于不同Kind
apiVersion: batch/v1beta1 ##版本不同
kind: CronJob ##类型不一样
metadata:
name: CronJobname
spec:
schedule: "*/1 * * * *" ##分时日月周
jobTemplate: ##一次性任务的模板信息
spec:
template: ##Pod模板信息
spec:
containers:
- name: dockername
image: nginx
command: ["/bin/bash","-c","-- sleep 30000"]
Kubernetes cluster
restartPolicy: OnFailure ##重启策略，只能为Never或OnFailure7，相关命令
例：应用，删除，查看一次性Job日志,查看job，cronjob，deamonset
kubectl apply -f filename.yaml
kubectl delete job jobname
kubectl delete cronjob cronjobname
kubectl delete deamonset deamonsetname
kubectl logs jobname
kubectl get job/cronjob/deamonset
九，Pod健康检查
1，概念
简单来说就是Kubernets借助不同种类的探针来检查Pod是否正常运行或正常提供服务
2，探针的种类
Liveness探针：存活探针，用于捕获容器是否处于存活状态，若失败，会尝试重启策略恢复容器。
Readiness探针：就绪探针，顾名思义，就是检查Pod是否准备好对外提供服务，若没有，则会将Pod从匹配的endpointcontroller中删掉。
3，实现方法Handler
两种种类的探针使用的都是以下三种实现方法。
ExecAction：在容器内执行命令来诊断是否成功。
TCPSockerAction：对指定端口上的容器的IP地址进行TCP检查，端口打开为成功。
HTTPGetAction：对指定端口上的容器的IP地址执行HTTP Get请求，若返回码>=200且<400，则为成功。
4、存活性探测livenessProbe和就绪性探测readinessProbe的区别是什么？
| 存活探针（livenessProbe） | 就绪探针（readinessProbe） | |
| Pod出错时 | 杀死出错Pod，重启Pod | 等待 |
| 服务 | Endpoint中自动更新Pod信息 | 从Endpoint删除错误的Pod |
| 功能 | 查看Pod是否存活 | 查看Pod是否准备好提供服务 |
5、两种探针都支持的三种探测方法是，检测判断依据是什么？
| 三种探测方式 | 判断依据 |
| ExecAction | 进入容器，执行一条命令 |
| TCPSocketAction | Tcp端口是否成功 |
| HTTPGetAction | Http服务获取值是否在[200,400) |
6、探针探测结果有哪三种值？
| 三种探测方式 | 探测结果 |
| ExecAction | 0成功，其余失败 |
| TCPSocketAction | Tcp端口打开则成功，否则为是被 |
| HTTPGetAction | Http服务响应状态码在[200,400)为成功，否则为失败。 |
7，存活探针execaction
使用方法就是在pod资源清单文件中containers内容下加入如下代码：
spec:
containers:
- name: dockernaem
image: centos
args:
- /bin/bash
- -c
- touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
livenessProbe: ##探针的类型
exec: ##探针的实现方法
command:
- cat
- /tmp/healthy
initialDelaySeconds: 5 ##探测延迟5秒
periodSeconds: 5 ##探测周期5秒
默认情况下，三次探测失败，则认为容器不存活，一次探测成功，则认为容器存活。这个默认次数可变。
8，存活探针TCP
spec:
containers:
- name: dockername
image: centos
livenessProbe: ##探针类型
tcpSocket: ##探针实现方法
port: 23 ##检查的端口
initialDelaySeconds: 60
periodSeconds: 209，存活探针HTTP
spec:
containers:
- name: dockername
image: centos
livenessProbe: ##探针类型
httpGet: ##探针实现方法
port: 8080
httpHeaders:
- name: headersname
value:10，就绪探针
把livernessProbe改为readinessProbe即可，其他都一样，只是处理方式不同。
十，Kubernetes存储
1，Kubernetes的存储方式
emptyDir：当Pod被成功分配到某个节点时，就会自动创建一个emptyDir，只要Pod在这个节点上，emptyDir就一直在，Pod无emptyDir也随之永远删除。虽方便，但不安全。
君生即我生，君去随君去
pod有，我就有，pod无，我也无
HostPath：需在pod被分配到的node节点上建一个目录，但因为不知道pod会被分配到哪个节点，所以要每个节点都建一个目录（弊端），pod删除后，目录及文件依然在。
君生伴我生，君去我不去
PV和PVC：pv：由管理员配置的一块存储空间，是集群中的资源，可以是NFS，云存储等等。PVC：用户的存储请求，去请求pv
２，emptyDir
就是在Pod的资源清单里通过volumes字段挂载
spec:
containers:
- image: centos
name: docekrname
volumeMounts: ##挂载卷
- mountPath: /ceshi ##容器内路径
name: ceshi-volume ##通过名字去匹配卷
volumes: ##卷
- name: ceshi-volume ##卷名
empytyDir: {} ##大小3，HostPath
volumeMounts:
- mountPath: /tmp
name: test
volumes：
- name: test
hostPath:
path: /tmp
type: Directory4，创建pv，pvc
apiVersion: v1
kind: PersistentVolume ##类型pv
metadata:
name: jpzpv1
spec:
capacity: ##大小
storage: 1Gi
accessModes: ##访问模式
- ReadWriteMany ##多次读写
persistentVolumeReclaimPolicy: Recycle ##回收策略
storageClassName: jpz-sc
nfs:
path: /nfs/jpzpv1
server: 192.168.100.31访问模式：Read'Write'Once： 读写模式，一个节点。
ReadOnlyMany：只读模式，多个节点。
Read Write Many：读写模式，多个节点，同时加载。
回收策略：Retain：保留，手动删除 Reycle：回收 Delete：删除
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: jpzpvc1
spec:
accessModes: ##和pv一样
- ReadWriteMany
volumeName: jpzpv1 ##匹配pv名
resources:
requests:
storage: 1Gi其实关于pv和pvc还有很多没有涉及到的，深入学习的话还需学习其它文章。
十一，ConfigMip与Secret
1，Config
用于保存非机密性的配置（明文配置），数据通过key--value的键值对形式存储，也可以是文件。
Config可以做成Volume，通过volume的方式映射到容器内部目录，从而实现对容器内部配置文件更方便的统一管理。局限性是数据不可超过1MB。
2，Secret
用于存放一些敏感数据内容，如密码，密钥等数据，保证这些数据不会暴露到镜像或者Pod Spec中。
十二，StatefulSet
1，无状态与有状态
无状态stateless：无持久化存储，IP地址变换，
有状态stateful：持久化的存储，通过pvc，稳定的网络，通过Headless Service，Pod基于序号的有序操作。
2，创建有状态的三个步骤
搭建存储服务器，如nfs，创建pv和pvc。创建StatefulSet（它包含了pvc）。创建Headless Se rvice，无固定IP的方式被请求。
十三，kubernets服务质量QoS
spec:
containers:
- name:
image:
resources:
limits:
memory: ""
cpu: ""
requests:
memory: ""
cpu: ""1，Best-Effort
没有limit和request
2，Burstable
中级：一般limit>request
3，Guaranteed
最高级别，requests和limits数值一样
结语
后来老师讲了复习之后，我就感觉我写的太详细了，于是后边就写的简单了些，只写了考点，也是快考试没时间了，这篇文章就先这样吧，等到以后有时间了，我会把每一部分，尤其是后边的再细化，可以作为一个简单的学习手册来用。
这篇文章写了好长时间，因为一直有课，挺不容易的，一万三千字，大家多多支持吧！有错误的话欢迎指出。
K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容
更多推荐
15
0- 0
已为社区贡献1条内容
所有评论(0)