Yaml文件解释

apiVersion：api版本信息
kind：资源对象的类别
metadata：元数据名称字段必写。
spec：用户期望的状态。
labels：定义pod的标签
status：资源现在处于什么样的状态
replicas：定义副本数量
selector：标签选择器，定义匹配pod的标签
template：pod的模板定义
containers：容器定义

添加apiVersion库

在yaml文件中command指令下添加

[root@master yaml]# vim /etc/kubernetes/manifests/kube-apiserver.yaml
......
spec:
  containers:
  - command:
    - kube-apiserver
    - --runtime-config=batch/v2alpha1=true    #添加
    
[root@master ~]# systemctl  restart kubelet.service 
[root@master ~]# kubectl  api-versions
......
batch/v2alpha1
......

一、NameSpace

PS：NameSpace资源对象仅用于资源对象的隔离，并不能隔绝不同名称空间的pod之间的通信，因为那是网络策略资源的功能。

Kubernetes中的集群默认会有一个叫default的namespace。实际上，应该是3个：

default：你的service和app默认被创建于此。
kube-system：kubernetes系统组件使用。
kube-public：公共资源使用。但实际上现在并不常用。

[root@master yaml]# kubectl  get ns
NAME              STATUS   AGE
default           Active   23d
kube-public       Active   23d
kube-system       Active   23d

1.1 命令行创建

创建、查看名称空间、查看名称空间详细信息、删除名称空间

[root@master ~]# kubectl  create namespace  test
namespace/test created
[root@master ~]# kubectl  create namespace  test
namespace/test created
[root@master ~]# kubectl  get namespaces  test
NAME   STATUS   AGE
test   Active   56s
[root@master ~]# kubectl describe  namespaces  test 
Name:         test
Labels:       <none>
Annotations:  <none>
Status:       Active

No resource quota.

No resource limits.
[root@master ~]# kubectl  delete  namespaces  test 
namespace "test" deleted

PS：轻易不要删除名称空间，因为删除之后，在此名称空间之下资源会全部删除。

1.2 yaml文件创建

[root@master ~]# cd yaml/
[root@master yaml]# vim namespace.yaml

kind: Namespace
apiVersion: v1
metadata: 
  name: test
  
[root@master yaml]# kubectl  apply  -f  namespace.yaml 
namespace/test created
[root@master yaml]# kubectl  get ns  test 
NAME   STATUS   AGE
test   Active   27m

二、Deployment

2.1 命令行创建

创建、查看deploy控制器、查看deploy资源详细信息

[root@master ~]# kubectl  run  t1 --image=nginx --replicas=3
deployment.apps/t1 created
[root@master ~]# kubectl  get deployments.
NAME    READY   UP-TO-DATE   AVAILABLE   AGE
t1      3/3     3            2           35s
[root@master ~]# kubectl  describe  deployments. t1 
Name:                   t1
Namespace:              default
CreationTimestamp:      Mon, 02 Nov 2020 15:22:51 +0800
Labels:                 run=t1
Annotations:            deployment.kubernetes.io/revision: 1
Selector:               run=t1
Replicas:               3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:
  Labels:  run=t1
  Containers:
   t1:
    Image:        nginx
    Port:         <none>
    Host Port:    <none>
    Environment:  <none>
    Mounts:       <none>
  Volumes:        <none>
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Available      True    MinimumReplicasAvailable
  Progressing    True    NewReplicaSetAvailable
OldReplicaSets:  <none>
NewReplicaSet:   t1-55f6c78557 (3/3 replicas created)
Events:
  Type    Reason             Age   From                   Message
  ----    ------             ----  ----                   -------
  Normal  ScalingReplicaSet  64s   deployment-controller  Scaled up replica set t1-55f6c78557 to 3

2.2 yaml文件创建

PS：创建一个deploy资源，名叫t2、添加名称空间test、镜像使用nginx

[root@master yaml]# vim deployment.yaml

kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: t2
  namespace:  test
spec:
  replicas: 3
  template:
    metadata:
      labels: 
        app:  t2
    spec:
      containers:
      - name: t2
        image:  nginx

[root@master yaml]# kubectl  apply  -f  deployment.yaml 
deployment.extensions/t2 created
[root@master yaml]# kubectl  get deployments. -n test 
NAME   READY   UP-TO-DATE   AVAILABLE   AGE
t2     3/3     3            3           34s

三、Service

3.1 命令行创建

PS：如果想要外网能够访问服务，可以暴露deployment资源，得到service资源，但svc资源的类型必须为NodePort

创建、查看、查看详细信息

扫描二维码关注公众号，回复： 12353168 查看本文章

[root@master ~]# kubectl  expose  deployment  t1 --name=t1-svc  --port=80 --type=NodePort
service/web-svc exposed
[root@master ~]# kubectl  get svc
NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
t1-svc      NodePort    10.103.79.74    <none>        80:31880/TCP     8s
[root@master ~]# curl  10.103.79.74 
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
......
[root@master ~]# kubectl  describe  svc t1-svc 
Name:                     t1-svc
Namespace:                default
Labels:                   run=t1
Annotations:              <none>
Selector:                 run=t1
Type:                     NodePort
IP:                       10.102.137.239
Port:                     <unset>  80/TCP
TargetPort:               80/TCP
NodePort:                 <unset>  31417/TCP
Endpoints:                10.244.1.3:80,10.244.2.2:80,10.244.2.3:80
Session Affinity:         None
External Traffic Policy:  Cluster
Events:                   <none>

3.2 yaml文件创建

PS：添加名称空间

[root@master ~]# vim service.yaml

kind: Service
apiVersion: v1
metadata: 
  name: t2-svc
  namespace:  test
spec:
  type: NodePort
  selector:
    app:  t2
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
    nodePort: 30031


[root@master ~]# kubectl  apply  -f  service.yaml 
service/t2-svc created
[root@master ~]# kubectl  get svc -n test  t2-svc 
NAME     TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
t2-svc   NodePort   10.109.99.243   <none>        80:30031/TCP   77s
[root@master ~]# curl  10.109.99.243
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
......

四、Pod

4.1 创建Pod

[root@master yaml]# vim pod.yaml

kind: Pod
apiVersion: v1
metadata:
  name: test-pod
  namespace:  test
spec:
  containers:
  - name: test-pod
    image:  httpd

[root@master yaml]# kubectl  apply  -f  pod.yaml 
pod/test-pod created
[root@master yaml]# kubectl  get pod -n test test-pod 
NAME       READY   STATUS    RESTARTS   AGE
test-pod   1/1     Running   0          38s

4.2 容器镜像获取策略

k8s默认根据镜像的TAG不同，有三种不同策略

Always：镜像标签为"latest"或镜像标签不存在时，总是从指定的仓库（默认的官方仓库、或者私有仓库）中获取最新镜像。
IfNotPresent：仅当本地镜像不存在时才从目标仓库中下载。也就意味着，如果本地存在，直接使用本地镜像，无需再联网下载。
Never：禁止从仓库中下载镜像，即只使用本地镜像。

[root@master yaml]# vim pod1.yaml 

kind: Pod
apiVersion: v1
metadata:
  name: test-pod1
  namespace:  test
spec:
  containers:
  - name: test-pod
    image:  httpd
    imagePullPolicy:  IfNotPresent

[root@master yaml]# kubectl  apply  -f  pod1.yaml 
pod/test-pod1 created
[root@master yaml]# kubectl  get pod -n test test-pod1
NAME        READY   STATUS    RESTARTS   AGE
test-pod1   1/1     Running   0          2m42s

4.3 容器的重启策略

k8s默认重启策略有三种

Always：但凡Pod对象终止就将其重启，此为默认设定。
OnFailure：仅在Pod对象出现错误时才将其重启。
Never：从不重启。

[root@master yaml]# vim pod2.yaml 

kind: Pod
apiVersion: v1
metadata:
  name: test-pod2
  namespace:  test
spec:
  restartPolicy:  OnFailure
  containers:
  - name: test-pod
    image:  httpd
    imagePullPolicy:  IfNotPresent

[root@master yaml]# kubectl  apply  -f  pod2.yaml 
pod/test-pod2 created
[root@master yaml]# kubectl  get  pod -n test  test-pod2 
NAME        READY   STATUS    RESTARTS   AGE
test-pod2   1/1     Running   0          25s

4.4 容器默认健康检查

Kubelet使用liveness probe（存活探针）来确定何时重启容器。例如，当应用程序处于运行状态但无法做进一步操作，liveness探针将捕获到deadlock，重启处于该状态下的容器，使应用程序在存在bug的情况下依然能够继续运行下去。
Kubelet使用readiness probe（就绪探针）来确定容器是否已经就绪可以接受流量。只有当Pod中的容器都处于就绪状态时kubelet才会认定该Pod处于就绪状态。该信号的作用是控制哪些Pod应该作为service的后端。如果Pod处于非就绪状态，那么它们将会被从service的load balancer中移除。

4.4.1 Probe支持三种检查方法

1.exec

在用户容器内执行一次命令，如果命令执行的退出码为0，则认为应用程序正常运行，其他任务应用程序运行不正常。

	livenessProbe:
	  exec:
		command:
		- cat
		- /tmp/test

2.TCPSocket

尝试打开一个用户容器的Socket连接（就是IP地址：端口）如果能够建立这条连接，则认为应用程序正常运行，否则认为应用程序运行不正常。

	livenessProbe:
	tcpSocket:
		port:	8080

3.HTTPGet

调用容器内Web应用的web hook，如果返回的HTTP状态码在200和399之间，则认为应用程序正常运行，否则认为应用程序运行不正常。每进行一次HTTP健康检查都会访问一次指定的URL.

	httpGet: #通过httpget检查健康，返回200-399之间，则认为容器正常
 	  path: / #URI地址
      port: 80 #端口号
      host: 127.0.0.1 #主机地址
      scheme: HTTP #支持的协议，http或者https
httpHeaders：’’ #自定义请求的header

4.4.2 参数说明

initialDelaySeconds：容器启动后第一次执行探测是需要等待多少秒。
periodSeconds：执行探测的频率。默认是10秒，最小1秒。
timeoutSeconds：探测超时时间。默认1秒，最小1秒。
successThreshold：探测失败后，最少连续探测成功多少次才被认定为成功。默认是1。对于liveness必须是1。最小值是1。

探针探测的结果有以下三者之一

Success：Container通过了检查。
Failure：Container未通过检查。
Unknown：未能执行检查，因此不采取任何措施。

4.4.3 LivenessProbe（活跃度、存活性）

[root@master yaml]# vim livenessprobe.yaml

kind: Pod
apiVersion: v1
metadata:
  name: liveness
  labels:
    test: liveness
spec:
  restartPolicy: OnFailure
  containers:
  - name: liveness
    image: busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/test; sleep 60; rm -rf /tmp/test; sleep 300
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/test
      initialDelaySeconds: 10 
      periodSeconds: 5 

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

PS：此pod文件创建了一个容器，periodSeconds规定了kubelet每隔5秒执行一次liveness probe，initialDelaySeconds告诉kubele在第一次执行probe之前要等待10秒钟，探针检测命令是在容器中执行 cat /tmp/test 命令。如果执行成功，将返回0，kubelet将会认为容器是活着的并且很健康，如果返回是非0值，kubelet就会杀掉这个容器并且重启它。

[root@master yaml]# kubectl get pod 
NAME                     READY   STATUS    RESTARTS   AGE
liveness                 1/1     Running   1          4m26s
liveness                 1/1     Running   2          4m59s
......

Liveness活跃度探测，根据探测某个文件是否存在，来确定某个服务是否正常运行，如果存在则正常，否则，它会根据你设置的Pod的重启策略操作Pod。

4.4.4 Readiness （敏捷探测、就绪性探测）

ReadinessProbe探针的使用场景livenessProbe稍有不同，有的时候应用程序可能暂时无法接受请求，比如Pod已经Running了，但是容器内应用程序尚未启动成功，在这种情况下，如果没有ReadinessProbe，则Kubernetes认为它可以处理请求了，然而此时，我们知道程序还没启动成功是不能接收用户请求的，所以不希望kubernetes把请求调度给它，则使用ReadinessProbe探针。
ReadinessProbe和livenessProbe可以使用相同探测方式，只是对Pod的处置方式不同，ReadinessProbe是将Pod IP:Port从对应的EndPoint列表中删除，而livenessProbe则删除容器并根据Pod的重启策略来决定作出对应的措施。
ReadinessProbe探针探测容器是否已准备就绪，如果未准备就绪则kubernetes不会将流量转发给此Pod。
ReadinessProbe探针与livenessProbe一样也支持exec的探测方式，配置方式相同，只不过是将livenessProbe字段修改为ReadinessProbe。

[root@master yaml]# vim readiness.yaml

kind: Pod
apiVersion: v1
metadata:
  name: readiness
  labels:
    test: readiness
spec:
  restartPolicy: OnFailure
  containers:
  - name: readiness
    image: busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/test; sleep 60; rm -rf /tmp/test; sleep  300
    readinessProbe:
      exec:
        command:
        - cat
        - /tmp/test
      initialDelaySeconds: 10
      periodSeconds: 5

[root@master yaml]# kubectl  apply  -f  readiness.yaml 
pod/readiness created
[root@master yaml]# kubectl  get pod readiness -w
NAME        READY   STATUS    RESTARTS   AGE
readiness   0/1     Running   0          4m11s

4.4.5 总结liveness和readiness探测

liveness和readiness是两种健康检查机制，k8s将两种探测采取相同的默认行为，即通过判断容器启动进程的返回值是否为零，来判断探测是否成功。
两种探测配置方法完全一样，不同之处在于探测失败后的行为。
- liveness探测是根据重启策略操作容器，大多数是重启容器。
- readiness则是将容器设置为不可用，不接收Service转发的请求。
两种探测方法可建议独立存在，也可以同时存在。用livensess判断是否需要重启，实现自愈；用readiness判断容器是否已经准备好对外提供服务。

4.4.6 在扩容中使用

[root@master yaml]# vim kuorong.yaml

kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: kuorong
spec:
  replicas: 3
  template:
    metadata:
      labels:
        run:  kuorong
    spec:
      containers:
      - name: kuorong
        image:  httpd
        ports:
        - containerPort:  80
        readinessProbe:
          httpGet:
            scheme: HTTP
            path: /healthy
            port: 80
          initialDelaySeconds:  10
          periodSeconds:  5
---
kind: Service
apiVersion: v1
metadata:
  name: kuorong-svc
spec:
  type: NodePort
  selector:
    run: kuorong
  ports:
  - protocol: TCP
    port: 90
    targetPort: 80
    nodePort: 30321

[root@master yaml]# kubectl  apply  -f  kuorong.yaml 
deployment.extensions/kuorong created
service/kuorong-svc created

PS：服务扩容中，如果没有针对性就绪探测，往往扩容之后，表面看Pod的状态是没有问题的，但其实Pod内的服务是否运行正常也是我们要关注的，而Readiness的关注点就在这，如果Pod内的服务运行有问题，那么，这些新扩容的Pod就不会被添加到Service资源的转发中，从而保证用户能够有最起码正常的服务体验。

[root@master yaml]# kubectl  get pod 
NAME                       READY   STATUS      RESTARTS   AGE
kuorong-79fc944586-czgpz   0/1     Running     0          91s
kuorong-79fc944586-m9rdm   0/1     Running     0          91s
kuorong-79fc944586-vjxbr   0/1     Running     0          91s
[root@master yaml]# kubectl  exec  -it kuorong-79fc944586-czgpz bash
root@kuorong-79fc944586-czgpz:/usr/local/apache2# cd htdocs/
root@kuorong-79fc944586-czgpz:/usr/local/apache2/htdocs# ls
index.html
root@kuorong-79fc944586-czgpz:/usr/local/apache2/htdocs# 
root@kuorong-79fc944586-czgpz:/usr/local/apache2/htdocs# mkdir healthy
root@kuorong-79fc944586-czgpz:/usr/local/apache2/htdocs# ls
healthy  index.html
root@kuorong-79fc944586-czgpz:/usr/local/apache2/htdocs# exit
exit
[root@master mysql]# kubectl  get pod
NAME                       READY   STATUS      RESTARTS   AGE
kuorong-79fc944586-czgpz   1/1     Running     0          4m1s
kuorong-79fc944586-m9rdm   0/1     Running     0          4m1s
kuorong-79fc944586-vjxbr   0/1     Running     0          4m1s

4.4.7 在更新过程中使用

[root@master yaml]# vim gengxin.yaml

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: app
spec:
  replicas: 10
  template:
    metadata:
      labels:
        run: app
    spec:
      containers:
      - name: app
        image: busybox
        args:
        - /bin/sh
        - -c
        - sleep 10; touch /tmp/healthy; sleep 3000
        readinessProbe:
          exec:
            command:
            - cat
            - /tmp/healthy
          initialDelaySeconds: 10
          periodSeconds: 5
          
[root@master yaml]# kubectl apply  -f  gengxin.yaml  --record 
deployment.extensions/app created
[root@master yaml]# kubectl  rollout  history deployment  app 
deployment.extensions/app 
REVISION  CHANGE-CAUSE
1         kubectl apply --filename=gengxin.yaml --record=true
[root@master yaml]# kubectl  get  pod 
NAME                       READY   STATUS             RESTARTS   AGE
app-68b9b5ddb4-465zv       1/1     Running            0          9m28s
app-68b9b5ddb4-58cbw       1/1     Running            0          9m28s
app-68b9b5ddb4-6xbvd       1/1     Running            0          9m28s
app-68b9b5ddb4-7f5v4       1/1     Running            0          9m28s
app-68b9b5ddb4-bdn5r       1/1     Running            0          9m28s
app-68b9b5ddb4-dvdhv       1/1     Running            0          9m28s
app-68b9b5ddb4-ls2k9       1/1     Running            0          9m28s
app-68b9b5ddb4-rlf8q       1/1     Running            0          9m28s
app-68b9b5ddb4-tnzqf       1/1     Running            0          9m28s
app-68b9b5ddb4-vpw99       1/1     Running            0          9m28s

4.4.7.2 升级一下deployment

[root@master yaml]# cp gengxin.yaml gengxin1.yaml
[root@master yaml]# vim gengxin1.yaml 

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: app
spec:
  replicas: 10
  template:
    metadata:
      labels:
        run: app
    spec:
      containers:
      - name: app
        image: busybox
        args:
        - /bin/sh
        - -c
        - sleep 3000     #修改  
        readinessProbe:
          exec:
            command:
            - cat
            - /tmp/healthy
          initialDelaySeconds: 10
          periodSeconds: 5


[root@master yaml]# kubectl  apply  -f  gengxin1.yaml  --record 
deployment.extensions/app configured
[root@master yaml]# kubectl  rollout history deployment app 
deployment.extensions/app 
REVISION  CHANGE-CAUSE
1         kubectl apply --filename=gengxin.yaml --record=true
2         kubectl apply --filename=gengxin1.yaml --record=true
[root@master yaml]# kubectl  get pod 
NAME                       READY   STATUS             RESTARTS   AGE
app-68b9b5ddb4-7w77z       1/1     Running            0          116s
app-68b9b5ddb4-854vv       1/1     Running            0          116s
app-68b9b5ddb4-gmgs5       1/1     Running            0          116s
app-68b9b5ddb4-grxvs       1/1     Running            0          116s
app-68b9b5ddb4-jprz9       1/1     Running            0          116s
app-68b9b5ddb4-psgv6       1/1     Running            0          116s
app-68b9b5ddb4-qbgs6       1/1     Running            0          116s
app-68b9b5ddb4-qtnfw       1/1     Running            0          116s
app-68b9b5ddb4-wtzp8       1/1     Running            0          116s
app-7d7559dd99-qk4l2       0/1     Running            0          110s
app-7d7559dd99-vxt4n       0/1     Running            0          110s

4.4.7.3 再次升级一下deployment

[root@master yaml]# cp gengxin1.yaml gengxin2.yaml 

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: app
spec:
  replicas: 10
  template:
    metadata:
      labels:
        run: app
    spec:
      containers:
      - name: app
        image: busybox
        args:
        - /bin/sh
        - -c
        - sleep 3000      

[root@master yaml]# vim gengxin2.yaml 
[root@master yaml]# kubectl  apply  -f  gengxin2.yaml --record 
deployment.extensions/app configured
[root@master yaml]# kubectl  rollout  history  deployment  app 
deployment.extensions/app 
REVISION  CHANGE-CAUSE
1         kubectl apply --filename=gengxin.yaml --record=true
2         kubectl apply --filename=gengxin1.yaml --record=true
3         kubectl apply --filename=gengxin2.yaml --record=true
[root@master yaml]# kubectl  get pod
NAME                       READY   STATUS             RESTARTS   AGE
app-ffb66fc54-6gl4w        1/1     Running            0          111s
app-ffb66fc54-9nl7t        1/1     Running            0          59s
app-ffb66fc54-hstxr        1/1     Running            0          51s
app-ffb66fc54-jpw5j        1/1     Running            0          77s
app-ffb66fc54-mxxjr        1/1     Running            0          2m8s
app-ffb66fc54-qcjmq        1/1     Running            0          63s
app-ffb66fc54-wfwps        1/1     Running            0          111s
app-ffb66fc54-wlbqk        1/1     Running            0          94s
app-ffb66fc54-wt6mj        1/1     Running            0          2m8s
app-ffb66fc54-xvznq        1/1     Running            0          72s

4.5 回滚

4.5.1回滚2版本

[root@master yaml]# kubectl  get pod
NAME                       READY   STATUS      RESTARTS   AGE
app-7d7559dd99-jdlbd       0/1     Running     0          74s
app-7d7559dd99-lfd9p       0/1     Running     0          74s
app-ffb66fc54-6gl4w        1/1     Running     0          5m35s
app-ffb66fc54-9nl7t        1/1     Running     0          4m43s
app-ffb66fc54-jpw5j        1/1     Running     0          5m1s
app-ffb66fc54-mxxjr        1/1     Running     0          5m52s
app-ffb66fc54-qcjmq        1/1     Running     0          4m47s
app-ffb66fc54-wfwps        1/1     Running     0          5m35s
app-ffb66fc54-wlbqk        1/1     Running     0          5m18s
app-ffb66fc54-wt6mj        1/1     Running     0          5m52s
app-ffb66fc54-xvznq        1/1     Running     0          4m56s[root@master yaml]# kubectl  rollout  history  deployment  app 
deployment.extensions/app 
REVISION  CHANGE-CAUSE
1         kubectl apply --filename=gengxin.yaml --record=true
2         kubectl apply --filename=gengxin1.yaml --record=true
3         kubectl apply --filename=gengxin2.yaml --record=true
[root@master yaml]# kubectl  rollout  undo deployment app --to-revision=2
deployment.extensions/app rolled back
[root@master yaml]# kubectl  get pod
NAME                       READY   STATUS      RESTARTS   AGE
app-7d7559dd99-jdlbd       0/1     Running     0          74s
app-7d7559dd99-lfd9p       0/1     Running     0          74s
app-ffb66fc54-6gl4w        1/1     Running     0          5m35s
app-ffb66fc54-9nl7t        1/1     Running     0          4m43s
app-ffb66fc54-jpw5j        1/1     Running     0          5m1s
app-ffb66fc54-mxxjr        1/1     Running     0          5m52s
app-ffb66fc54-qcjmq        1/1     Running     0          4m47s
app-ffb66fc54-wfwps        1/1     Running     0          5m35s
app-ffb66fc54-wlbqk        1/1     Running     0          5m18s
app-ffb66fc54-wt6mj        1/1     Running     0          5m52s
app-ffb66fc54-xvznq        1/1     Running     0          4m56s

4.5.2 编写一个yaml文件

在更新过程中，期望的Replicas值为10个，更改rollingupdate策略，要求在更新过程中，最大不可用Pod的值为2个，允许同时出现的Pod的总数量为12个。

[root@master yaml]# vim huigun.yaml

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: app
spec:
  strategy:
    rollingUpdate:
      maxSurge: 2
      maxUnavailable: 2
  replicas: 10
  template:
    metadata:
      labels:
        run: app
    spec:
      containers:
      - name: app
        image: busybox
        args:
        - /bin/sh
        - -c
        - sleep 3000
        readinessProbe:
          exec:
            command:
            - cat
            - /tmp/healthy
          initialDelaySeconds: 10
          periodSeconds: 5

maxSurge: 此参数控制滚动更新过程中，副本总数超过预期数（replicas）的值。可以是整数，也可以是百分比，默认是1。
maxUnavailable：不可用Pod的值。默认为1.可以是整数，也可以是百分比。

[root@master yaml]# kubectl  apply  -f  huigun.yaml --record 
deployment.extensions/app configured
[root@master yaml]# kubectl  rollout  history  deployment  app 
deployment.extensions/app 
REVISION  CHANGE-CAUSE
1         kubectl apply --filename=gengxin.yaml --record=true
3         kubectl apply --filename=gengxin2.yaml --record=true
4         kubectl apply --filename=huigun.yaml --record=true

[root@master yaml]# kubectl  get  pod
NAME                       READY   STATUS             RESTARTS   AGE
app-7d7559dd99-ghrhp       0/1     Running            0          76s
app-7d7559dd99-jdlbd       0/1     Running            0          4m31s
app-7d7559dd99-lfd9p       0/1     Running            0          4m31s
app-7d7559dd99-zl46p       0/1     Running            0          76s
app-ffb66fc54-6gl4w        1/1     Running            0          8m52s
app-ffb66fc54-9nl7t        1/1     Running            0          8m
app-ffb66fc54-jpw5j        1/1     Running            0          8m18s
app-ffb66fc54-mxxjr        1/1     Running            0          9m9s
app-ffb66fc54-wfwps        1/1     Running            0          8m52s
app-ffb66fc54-wlbqk        1/1     Running            0          8m35s
app-ffb66fc54-wt6mj        1/1     Running            0          9m9s
app-ffb66fc54-xvznq        1/1     Running            0          8m13s

五、Job

服务类的Pod容器：RC、RS、DS、Deployment.（Pod内运行的服务，要持续运行）
工作类的Pod容器：Job—>执行一次，或者批量执行处理程序，完成之退出容器。
如果容器内执行任务有误，会根据容器的重启策略操作容器，不过在Job的容器重启策略只能是：Never和 OnFailure。

5.1 添加参数可以提高Job的执行效率

在Job.spec字段下加上parallelism选项。表示同时运行多少个Pod执行任务。
在Job.spec字段下加上completions选项。表示总共需要完成Pod的数量

......
spec:
	parallelism: 2
	completions: 8

示例：

5.2 Never：

[root@master yaml]# vim job.yaml 
kind: Job
apiVersion: batch/v1
metadata:
  name: test-job
spec:
  parallelism:  2
  completions:  8
  template:
    metadata:
      name: test-job
    spec:
      containers:
      - name: hello
        image:  busybox
        command:  ["echo","hello k8s job!"]
      restartPolicy:  Never
      
[root@master yaml]# kubectl  apply  -f  job.yaml 
job.batch/test-job created

执行以下命令会验证出结果

[root@master yaml]# kubectl  get pod -w
NAME             READY   STATUS              RESTARTS   AGE
test-job-mz8j8   0/1     ContainerCreating   0          11s
test-job-tf5gt   0/1     ContainerCreating   0          11s
test-job-mz8j8   0/1     Completed           0          11s
test-job-7bt4q   0/1     Pending             0          0s
test-job-7bt4q   0/1     Pending             0          0s
test-job-7bt4q   0/1     ContainerCreating   0          0s
test-job-tf5gt   0/1     Completed           0          12s
test-job-4qct9   0/1     Pending             0          0s
test-job-4qct9   0/1     Pending             0          0s
test-job-4qct9   0/1     ContainerCreating   0          0s
test-job-4qct9   0/1     Completed           0          8s
test-job-5f9b9   0/1     Pending             0          0s
test-job-5f9b9   0/1     Pending             0          0s
test-job-5f9b9   0/1     ContainerCreating   0          0s
[root@master yaml]# kubectl  get pod 
NAME             READY   STATUS      RESTARTS   AGE
test-job-2bjb9   0/1     Completed   0          67s
test-job-4qct9   0/1     Completed   0          77s
test-job-5f9b9   0/1     Completed   0          69s
test-job-7bt4q   0/1     Completed   0          78s
test-job-crjll   0/1     Completed   0          59s
test-job-mz8j8   0/1     Completed   0          89s
test-job-tf5gt   0/1     Completed   0          89s
test-job-ttm62   0/1     Completed   0          57s
[root@master yaml]# kubectl  logs  test-job-2bjb9 
hello k8s job!
[root@master yaml]# kubectl  logs  test-job-5f9b9 
hello k8s job!
[root@master yaml]# kubectl  logs  test-job-crjll 
hello k8s job!
......

PS：可以看到job与其他资源对象不同，仅执行一次性任务，默认pod运行后job即结束，状态Completed。

5.3OnFailure

为了验证重启策略成功，将yaml文件中的command内容改为乱码。

[root@master yaml]# cp job.yaml  job1.yaml 
[root@master yaml]# vim job1.yaml 

kind: Job
apiVersion: batch/v1
metadata:
  name: test-job1
spec:
  parallelism:  2
  completions:  8
  template:
    metadata:
      name: test-job1
    spec:
      containers:
      - name: hello
        image:  busybox 
        command:  ["sdadada","hello k8s job!"]   #修改
      restartPolicy:  OnFailure
      
[root@master yaml]# kubectl  apply  -f job1.yaml 
job.batch/test-job1 created

查看pod 是否一直重启？

[root@master yaml]# kubectl  get pod -w
NAME              READY   STATUS              RESTARTS   AGE
test-job1-6sn2v   0/1     RunContainerError   1          38s
test-job1-llcxf   0/1     RunContainerError   1          38s
test-job1-llcxf   0/1     CrashLoopBackOff    1          46s
test-job1-6sn2v   0/1     CrashLoopBackOff    1          49s
test-job1-llcxf   0/1     RunContainerError   2          63s
test-job1-llcxf   0/1     CrashLoopBackOff    2          78s
test-job1-6sn2v   0/1     RunContainerError   2          80s
......

PS：它会一直重启pod完成命令，直到重启到一定次数就会删除job。

六、CronJob

PS：CronJob就是一个设置定时执行的Job

在cronjob中也支持执行效率参数：

在cronjob.spec.jobTemplate.spec 字段下加上parallelism选项。表示同时运行多少个Pod执行任务。
在cronjob.spec.jobTemplate.spec 字段下加上completions选项。表示总共需要完成Pod的数量

6.1 编写Yaml文件

[root@master yaml]# vim cronjob.yaml 
kind: CronJob
apiVersion: batch/v1beta1
metadata:
  name: cronjob
spec:
  schedule: "*/1 * * * *"
  jobTemplate:
    spec:
     
      parallelism: 2
      completions: 8
      template:
        spec:
          containers:
          - name: cronjob
            image:  busybox
            command:
            - echo
            - /tmp/test.txt
          restartPolicy:  OnFailure
[root@master yaml]# kubectl  apply  -f  cronjob.yaml 
cronjob.batch/cronjob created

6.2 查看

PS：此时查看Pod的状态，会发现每分钟都会运行一个新Pod来执行命令规定的任务。

[root@master yaml]# kubectl  get pod -w
cronjob-1604475240-bl89v   0/1   Pending   0     0s
cronjob-1604475240-bl89v   0/1   Pending   0     0s
cronjob-1604475240-7kljq   0/1   Pending   0     0s
cronjob-1604475240-7kljq   0/1   Pending   0     0s
cronjob-1604475240-bl89v   0/1   ContainerCreating   0     0s
cronjob-1604475240-7kljq   0/1   ContainerCreating   0     0s
cronjob-1604475240-bl89v   0/1   Completed           0     17s
cronjob-1604475240-7kljq   0/1   Completed           0     17s
......
[root@master ~]# kubectl  get  pod
NAME                       READY   STATUS              RESTARTS   AGE
cronjob-1604475240-7kljq   0/1     Completed           0          2m13s
cronjob-1604475240-bl89v   0/1     Completed           0          2m13s
......

[root@master ~]# kubectl  logs  cronjob-1604475240-7kljq 
/tmp/test.txt
[root@master ~]# kubectl  logs  cronjob-1604475240-bl89v 
/tmp/test.txt

PS：此时仍然不能正常运行指定时间的cronJob，这是因为K8s官方在cronjob这个资源对象的支持中还没有完善此功能，还待开发。

七、ReplicaSet

[root@master yaml]# vim  ReplicaSet.yaml

apiVersion: extensions/v1beta1       //api版本定义
kind: ReplicaSet       //定义资源类型为ReplicaSet
metadata:       //元数据定义
    name: myapp       //ReplicaSet名称
spec:       //ReplicaSet的规格定义
    replicas: 2       //定义副本数量为2个
    selector:       //标签选择器，定义匹配pod的标签
        matchLabels:
            app: myapp
            release: canary
    template:       //pod的模板定义
        metadata:       //pod的元数据定义
            name: myapp-pod       //自定义pod的名称　
            labels:       //定义pod的标签，需要和上面定义的标签一致，也可以多出其他标签
                app: myapp
                release: canary
                environment: qa
        spec:       //pod的规格定义
            containers:       //容器定义
            - name: myapp-container       //容器名称
              image: ikubernetes/myapp:v1       //容器镜像
              ports:       //暴露端口
              - name: http
                containerPort: 80

八、DaemonSet

DaemonSet的升级策略：

OnDelete: 该策略表示当更新了DaemonSet的模板后，只有手动删除旧的DaemonSet Pod才会创建新的DaemonSet Pod
RollingUpdate：该策略表示当更新DaemonSet模板后会自动删除旧的DaemonSet Pod并创建新的DaemonSetPod

[root@master yaml]# vim  DaemonSet.yaml

kind: DaemonSet
apiVersion: extensions/v1beta1
metadata:
  name: daemonset
spec:
  updateStrategy:
    type: RollingUpdate
  template:
    metadata:
      labels:
        name: test-web
        app: httpd
    spec:
      containers:
      - name: web
        image: httpd
        ports:
        - containerPort: 80

九、Kube-Proxy（负载均衡）

kube-proxy是k8s的一个核心组件。每台机器上都运行一个kube-proxy服务，它监听API server中service和endpoint的变化情况，并通过iptables等来为后端服务配置负载均衡

通过上条命令看到了访问CLUSTER-IP ,后端的Pod会轮替着为我们提供服务，也就是负载均衡，如果没有Service资源，Kube-proxy组件也不会生效。

[root@master ~]# kubectl  get svc http-svc 
NAME       TYPE       CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE
http-svc   NodePort   10.103.132.109   <none>        80:31601/TCP   3h37m

通过describe命令，查看SVC资源对应的Endpoint，就能够知道后端真正的Pod。

[root@master ~]# kubectl  describe  svc http-svc 
......
Endpoints:                10.244.1.8:80,10.244.1.9:80,10.244.2.8:80
Session Affinity:         None
External Traffic Policy:  Cluster
Events:                   <none>

通过iptanbles规则，可以观察到底层的原理

目标地址是10.103.132.109/32的80端口，并且走的是TCP协议，那么就把这个流量跳就会转到KUBE-SVC-LLMSFKRLGJ6BVN7Z，用到了SNAT(源地址转换)

[root@master ~]# iptables-save  | grep 10.103.132.109
-A KUBE-SERVICES ! -s 10.244.0.0/16 -d 10.103.132.109/32 -p tcp -m comment --comment "default/http-svc: cluster IP" -m tcp --dport 80 -j KUBE-MARK-MASQ
-A KUBE-SERVICES -d 10.103.132.109/32 -p tcp -m comment --comment "default/http-svc: cluster IP" -m tcp --dport 80 -j KUBE-SVC-LLMSFKRLGJ6BVN7Z

然后继续分析，会查看到访问后端服务的机率，从而实现了svc能够随机访问到后端，MASQ（动态源地址转换）

[root@master ~]# iptables-save  | grep KUBE-SVC-LLMSFKRLGJ6BVN7Z
:KUBE-SVC-LLMSFKRLGJ6BVN7Z - [0:0]
-A KUBE-NODEPORTS -p tcp -m comment --comment "default/http-svc:" -m tcp --dport 31601 -j KUBE-SVC-LLMSFKRLGJ6BVN7Z
-A KUBE-SERVICES -d 10.103.132.109/32 -p tcp -m comment --comment "default/http-svc: cluster IP" -m tcp --dport 80 -j KUBE-SVC-LLMSFKRLGJ6BVN7Z
-A KUBE-SVC-LLMSFKRLGJ6BVN7Z -m statistic --mode random --probability 0.33332999982 -j KUBE-SEP-GKJOAGOA2547HWSI
-A KUBE-SVC-LLMSFKRLGJ6BVN7Z -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-P7NHLPBULC4DX3KP
-A KUBE-SVC-LLMSFKRLGJ6BVN7Z -j KUBE-SEP-4E2QKSE3ZPWCPABP

然后继续分析KUBE-SEP-GKJOAGOA2547HWSI，会看到它作用就是把网络流量通过DNAT发送到10.244.1.8的80端口，其他俩条也同样用到了DNAT（目标地址转换）

[root@master ~]# iptables-save  | grep KUBE-SEP-GKJOAGOA2547HWSI
:KUBE-SEP-GKJOAGOA2547HWSI - [0:0]
-A KUBE-SEP-GKJOAGOA2547HWSI -s 10.244.1.8/32 -j KUBE-MARK-MASQ
-A KUBE-SEP-GKJOAGOA2547HWSI -p tcp -m tcp -j DNAT --to-destination 10.244.1.8:80
-A KUBE-SVC-LLMSFKRLGJ6BVN7Z -m statistic --mode random --probability 0.33332999982 -j KUBE-SEP-GKJOAGOA2547HWSI

Linux——K8s集群资源