目录

扩展：

Pod创建的拓扑图：

提出的问题：

Pod 卷的使用：Pod的数据持久化问题

配置 Pod 以使用卷进行存储

参考文档：配置 Pod 以使用卷进行存储 | Kubernetes

有状态应用和无状态应用：

Pod 配置卷

 1、创建 Pod:

2、验证 Pod 中的容器是否正在运行，然后留意 Pod 的更改：

3、因为我们选择的创建卷的类型是emptyDir

4、如果我们在创建卷的时候使用的类型是hostPath：

Pod里的镜像的升级和回滚

参考网址：Deployments | Kubernetes

1、创建 Deployment

2、创建 Pod：

3、对nginx镜像进行升级（原nginx：1.14.2  升级后 nginx：1.16.1）

方法一：

方法二：直接修改deploy_nginx.yaml 文件中的nginx镜像版本，再重新运行该文件

发布的策略

参考文档：https://www.cnblogs.com/nulige/articles/10929182.html

回滚：就是我们可以将nginx的版本降低 ，从而形成Deployment的回滚

K8s的探针（probe）

kubelet的3种探针

参考文档：配置存活、就绪和启动探针 | Kubernetes

3种探针类型：存活探针（livenessProbe）、就绪探针（readinessProbe）、启动探针（startupProbe）

检查机制：使用探针来检查容器有四种不同的方法

添加存活、就绪和启动探针

实验：

---

扩展：

容器服务 ACK  --》阿里云提供支持的

容器服务 Kubernetes 版（简称 ACK）提供高性能可伸缩的容器应用管理能力，支持企业级容器化应用的全生命周期管理；2021年成为国内唯一连续三年入选Gartner公共云容器报告的产品，2022年国内唯一进入Forrester领导者象限。其整合了阿里云虚拟化、存储、网络和安全能力，助力企业高效运行云端Kubernetes容器化应用。

Pod创建的拓扑图：

提出的问题：

问题1：taints和 toleration是怎样查看的？如何知道那些机器上由污点，哪些Pod可以容忍？

查看某个节点的详细信息：（kubectl describe node表示所有节点的详细信息）

[root@master pod]# kubectl describe node master

查看master是否打过污点taints：（证明master打过污点taints）

[root@master pod]# kubectl describe node master | grep -i taints
Taints:             node-role.kubernetes.io/master:NoSchedule
[root@master pod]# 


grep -i 表示不区分大小写啦

查看Pod是否存在容忍度：

[root@master pod]# kubectl describe pod etcd-master -n kube-system | grep -i tolerations
Tolerations:       :NoExecute op=Exists
[root@master pod]# 

问题2：deployment：全自动调度：根据node的算力 --》它到底是如何跟node评分的（最底层的机制）

问题3：Pod亲和性调度算法，是否在你的工作中出现过导致某台node节点负载过高，从而出现故障

Pod 卷的使用：Pod的数据持久化问题

配置 Pod 以使用卷进行存储

参考文档：配置 Pod 以使用卷进行存储 | Kubernetes

只要容器存在，容器的文件系统就会存在，因此当一个容器终止并重新启动，对该容器的文件系统改动将丢失。 对于独立于容器的持久化存储，你可以使用卷。 这对于有状态应用程序尤为重要，例如键值存储（如 Redis）和数据库。

有状态应用和无状态应用：

有状态应用：有状态服务 可以说是 需要数据存储功能的服务、或者指多线程类型的服务，队列等。（mysql数据库、kafka、zookeeper等）

每个实例都需要有自己独立的持久化存储

在创建、删除、扩容/缩容和更新 StatefulSets 的 Pods，是需要讲究顺序的

mysql： 有状态 ： 启动的时候，必须按照顺序，并且pod是有固定的编号，不允许随机分配
    master ，slave
    写数据--》master上写

特点：缩容的时候是顺序进行的，不是随机的

无状态应用：

（1）、是指该服务运行的实例不会在本地存储需要持久化的数据，并且多个实例对于同一个请求响应的结果是完全一致的。

（2）、多个实例可以共享相同的持久化数据。例如：nginx实例，tomcat实例等

（3）、相关的k8s资源有：ReplicaSet、ReplicationController、Deployment等，由于是无状态服务，所以这些控制器创建的pod序号都是随机值。并且在缩容的时候并不会明确缩容某一个pod，而是随机的，因为所有实例得到的返回值都是一样，所以缩容任何一个pod都可以。

特点：

随便访问那个pod都会得到一样的结果

pod的序号是随机的

缩容的时候是随机进行的，删除或者增加，顺序是随机的

nginx： 无状态 ： 启动的时候，不必须按照顺序，并且pod是随机分配id
    web服务：  访问任意一个web服务器，得到结果都是一样的，而且网页数据也是从同一个地方获取

Pod 配置卷

在本练习中，你将创建一个运行 Pod，该 Pod 仅运行一个容器并拥有一个类型为 emptyDir 的卷， 在整个 Pod 生命周期中一直存在，即使 Pod 中的容器被终止和重启。以下是 Pod 的配置：

apiVersion: v1
kind: Pod
metadata:
  name: redis
spec:
  containers:
  - name: redis
    image: redis
    volumeMounts:
    - name: redis-storage
      mountPath: /data/redis
  volumes:
  - name: redis-storage
    emptyDir: {}

 1、创建 Pod:

[root@master pod]# kubectl apply -f redis.yaml 
pod/redis created
[root@master pod]# 

2、验证 Pod 中的容器是否正在运行，然后留意 Pod 的更改：

[root@master pod]# kubectl get pod redis --watch
NAME    READY   STATUS    RESTARTS   AGE
redis   1/1     Running   0          46s
^C[root@master pod]# 

--watch  表示时时监控，一旦Pod发生改变，它就会显示出来

3、因为我们选择的创建卷的类型是emptyDir

[root@master pod]# kubectl get pod redis -o wide
NAME    READY   STATUS    RESTARTS   AGE     IP           NODE    NOMINATED NODE   READINESS GATES
redis   1/1     Running   0          9m25s   10.244.2.5   node2   <none>           <none>
[root@master pod]# 

那么k8s会在node2上的/var/lib/docker/volums/上随机创建一个空文件夹来存放数据

并且是用来临时存放数据       

[root@node2 redis]# pwd
/var/lib/docker/volumes/1e3244a4c734b42343ed1a8a4b3f4a06030cbe1266a58b34b7b6e7fb54af06c4/_data/redis
[root@node2 redis]# 

4、如果我们在创建卷的时候使用的类型是hostPath：

可以确定volume卷的位置了，因为是自己定义上去的。 

Pod里的镜像的升级和回滚

参考网址：Deployments | Kubernetes

1、创建 Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

2、创建 Pod：

[root@master pod]# kubectl apply -f deploy_nginx.yaml 
deployment.apps/nginx-deployment created
[root@master pod]# 

3、对nginx镜像进行升级（原nginx：1.14.2  升级后 nginx：1.16.1）

方法一：

先来更新 nginx Pod 以使用 nginx:1.16.1 镜像，而不是 nginx:1.14.2 镜像。

kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1

或者使用下面的命令：

kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1

Deployment 可确保在更新时仅关闭一定数量的 Pod。默认情况下，它确保至少所需 Pod 的 75% 处于运行状态（最大不可用比例为 25%）。（滚动升级Deployment ）

如果仔细查看上述 Deployment ，将看到它首先创建了一个新的 Pod，然后删除旧的 Pod， 并创建了新的 Pod。它不会杀死旧 Pod，直到有足够数量的新 Pod 已经出现。 在足够数量的旧 Pod 被杀死前并没有创建新 Pod。它确保至少 3 个 Pod 可用， 同时最多总共 4 个 Pod 可用。 当 Deployment 设置为 4 个副本时，Pod 的个数会介于 3 和 5 之间。

查看升级后的Deployment中的nginx版本

[root@master pod]# kubectl describe pod nginx-deployment-ff6655784-bh5t5|grep Image:
    Image:          nginx:1.16.1
[root@master pod]# 

方法二：直接修改deploy_nginx.yaml 文件中的nginx镜像版本，再重新运行该文件

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

重新运行一次deploy_nginx.yaml文件

[root@master pod]# kubectl apply -f deploy_nginx.yaml 
deployment.apps/nginx-deployment configured
[root@master pod]# kubectl get pod -o wide
NAME                               READY   STATUS    RESTARTS   AGE     IP           NODE    NOMINATED NODE   READINESS GATES
k8s-nginx-6d779d947c-f72hf         1/1     Running   0          22h     10.244.1.4   node1   <none>           <none>
k8s-nginx-6d779d947c-hnhf5         1/1     Running   0          22h     10.244.3.2   node3   <none>           <none>
k8s-nginx-6d779d947c-xgjzg         1/1     Running   0          22h     10.244.2.2   node2   <none>           <none>
my-nginx-cf54cdbf7-8sbns           1/1     Running   0          6h9m    10.244.1.5   node1   <none>           <none>
my-nginx-cf54cdbf7-ptjw7           1/1     Running   0          5h56m   10.244.3.5   node3   <none>           <none>
my-nginx-cf54cdbf7-wf48x           1/1     Running   0          6h9m    10.244.2.4   node2   <none>           <none>
nginx-deployment-67dffbbbb-9kzj8   1/1     Running   0          7s      10.244.1.8   node1   <none>           <none>
nginx-deployment-67dffbbbb-m6qm8   1/1     Running   0          4s      10.244.2.8   node2   <none>           <none>
nginx-deployment-67dffbbbb-qfb2m   1/1     Running   0          6s      10.244.3.8   node3   <none>           <none>
redis                              1/1     Running   0          3h14m   10.244.2.5   node2   <none>           <none>
scnginx                            1/1     Running   0          16h     10.244.2.3   node2   <none>           <none>
[root@master pod]# kubectl describe pod nginx-deployment-67dffbbbb-qfb2m|grep Image:
    Image:          nginx:latest
[root@master pod]# 

发布的策略

金丝雀发布
蓝绿发布
灰度发布
滚动发布 

参考文档：https://www.cnblogs.com/nulige/articles/10929182.html

回滚：就是我们可以将nginx的版本降低 ，从而形成Deployment的回滚

你可能想要回滚 Deployment；例如，当 Deployment 不稳定时（例如进入反复崩溃状态）。 默认情况下，Deployment 的所有上线记录都保留在系统中，以便可以随时回滚 （你可以通过修改修订历史记录限制来更改这一约束）。

K8s的探针（probe）

probe 是由 kubelet 对容器执行的定期诊断。 要执行诊断，kubelet 既可以在容器内执行代码，也可以发出一个网络请求。

使用探针去试探pod是否能正常提供服务

kubelet的3种探针

参考文档：配置存活、就绪和启动探针 | Kubernetes

3种探针类型：存活探针（livenessProbe）、就绪探针（readinessProbe）、启动探针（startupProbe）

检查机制：使用探针来检查容器有四种不同的方法

添加存活、就绪和启动探针

 

实验：

参考实验文档：配置存活、就绪和启动探针 | Kubernetes

1、定义存活命令

2、定义一个存活态 HTTP 请求接口

3、定义 TCP 的存活探测

4、定义 gRPC 存活探针