K8s(1-2) pod详解，deployment控制器的使用，service微服务，资源清单的书写和示例，pod 的生命周期，容器探针的使用，k8s中的控制器类型_kubectl expose deployment

1.Kubernetes中的pod：

• Pod是可以创建和管理Kubernetes计算的最小可部署单元，一个Pod代表着集群中运行的一个进程，每个pod都有一个唯一的ip。
• 一个pod类似一个豌豆荚，包含一个或多个容器（通常是docker），多个容器间共享IPC、Network和UTC namespace。
• pod 是可以在 Kubernetes 中创建和管理的、最小的可部署的计算单元
• Pod （就像在鲸鱼荚或者豌豆荚中）是一组（一个或多个） 容器； 这些容器共享存储、网络、以及怎样运行这些容器的声明。 Pod 中的内容总是并置（colocated）的并且一同调度，在共享的上下文中运行。 Pod 所建模的是特定于应用的“逻辑主机”，其中包含一个或多个应用容器， 这些容器是相对紧密的耦合在一起的。 在非云环境中，在相同的物理机或虚拟机上运行的应用类似于在同一逻辑主机上运行的云应用。
• 就 Docker 概念的术语而言，Pod 类似于共享名字空间和文件系统卷的一组 Docker 容器。
每个 Pod 都旨在运行给定应用程序的单个实例。如果希望横向扩展应用程序（例如，运行多个实例 以提供更多的资源），则应该• • 使用多个 Pod，每个实例使用一个 Pod。 在 Kubernetes 中，这通常被称为 副本（Replication）。 通常使用一种工作负载资源及其控制器 来创建和管理一组 Pod 副本。

kubectl命令：https://kubernetes.io/docs/reference/generated/kubectl/kubectlcommands

kubectl get cs
kubectl get node
kubectl get pod -n kube-system   查看master端的状态；
kubectl get pod -o wide -n kube-system 查看每个节点的部署内容；

删除节点：
kubectl drain server3 --delete-local-data --force --ignore-daemonsets
kubectl delete node server3；
在 节点端：kubeadm reset  清除加入的缓存信息；
删除后可以使用token重新加入；

$ kubectl run nginx --image=nginx --replicas=2 --record
$ kubectl get pod查看pod的运行状态
$ kubectl get pod -o wide查看pod的运行位置
$ kubectl logs demo查看日志输出
$ kubectl describe pod demo查看pod的详细信息
注意：集群内部任意节点可以访问Pod，但集群外部无法直接访问。


$ kubectl create deployment myapp --image=nginx使用控制器部署pod
$ kubectl delete pod myapp-687598b8b4-ch84w删除pod，deployment会再次开启一个；
$ kubectl delete deployment.apps myapp彻底删除


$ kubectl create deployment myapp --image=nginx
$ kubectl scale deployment myapp --replicas=2
$ kubectl scale deployment myapp --replicas=5手动扩容
$ kubectl scale deployment myapp --replicas=2手动缩容


更新pod镜像：kubectl set image deployment nginx myapp=myapp:v2
查看历史版本  kubectl rollout history deployment nginx
回滚   kubectl rollout undo deployment nginx --to-revision=1

查看标签
kubectl get pod --show-labels
过滤标签（-l 或 -L）
[root@server2 ~]# kubectl get pod -L nginx
[root@server2 ~]# kubectl get pod -L run
打标签
kubectl label pod demo version=v1
更改标签
kubectl label pod demo app=nginx --overwrite

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

2.pod的创建和删除：

创建自主式pod：

在master端创建pod：

kubectl run nginx --image = ikubernetes/myapp:v1

删除pod：

kubectl delete pod nginx

3.控制管理器Deployment：

Deployment对象，顾名思义，是用于部署应用的对象。它使Kubernetes中最常用的一个对象，它为ReplicaSet和Pod的创建提供了一种声明式的定义方法，从而无需像之前那样手动创建ReplicaSet和Pod对象（使用Deployment而不直接创建ReplicaSet是因为Deployment对象拥有许多ReplicaSet没有的特性，例如滚动升级和回滚）。

通过Deployment对象，你可以轻松的做到以下事情：

创建ReplicaSet和Pod
滚动升级（不停止旧服务的状态下升级）和回滚应用（将应用回滚到之前的版本）
平滑地扩容和缩容
暂停和继续Deployment
1
2
3
4

示例演示：

kubectl create deployment nginx --image=ikubernetes/myapp:v1
deployment.apps/nginx created

使用deployment控制器管理pod时，用pod命令删除后会又自动创建一个新的;(但新的pod的rs不会改变：)

注意：如果想要彻底删除deployment中的pod时使用：
kubectl delete deployments nginx

Deployment的扩容和缩容：

–replicas：在deployment控制器的基础上：

kubectl scale deployment --replicas=2 nginx

4.service设定:

service是一个抽象概念，定义了一个服务的多个pod逻辑合集和访问pod的策略， 一般把service称为微服务。

Service可以看作是一组提供相同服务的Pod对外的访问接口。借助Service，应用可以方便地实现服务发现和负载均衡。 service默认只支持4层负载均衡能力，没有7层功能。（可以通过Ingress实现）

service的类型：
• ClusterIP：默认值，k8s系统给service自动分配的虚拟IP，只能在集群内部访问。
• NodePort：将Service通过指定的Node上的端口暴露给外部，访问任意一个 NodeIP:nodePort都将路由到ClusterIP。
• LoadBalancer：在 NodePort 的基础上，借助 cloud provider 创建一个外部的负 载均衡器，并将请求转发到 :NodePort，此模式只能在云服务器上使用。
• ExternalName：将服务通过 DNS CNAME 记录方式转发到指定的域名（通过 spec.externlName 设定）。

Service 是由 kube-proxy 组件，加上 iptables 来共同实现的.
• kube-proxy 通过 iptables 处理 Service 的过程，需要在宿主机上设置相当多的 iptables 规则，如果宿主机有大量的Pod，不断刷新iptables规则，会消耗大量的 CPU资源。
• IPVS模式的service，可以使K8s集群支持更多量级的Pod。

创建service:
$ kubectl expose deployment nginx --port=80 --target-port=80 此时pod客户端可以通过service的名称访问后端的两个Pod
ClusterIP: 默认类型，自动分配一个仅集群内部可以访问的虚拟IP

kubectl expose deployment myapp --port=80 --target-port=80暴露端口
kubectl get svc查看service
kubectl describe svc
kubectl get pod -o wide
kubectl get pod --show-labels 显示标签；

暴露deployment控制器中的名为nginx的pod的端口 ： 80

查看所有；services ； 详细的services:

可以实现负载均衡：

5.NodePort类型暴露端口，让外部客户端访问Pod:

$ kubectl edit svc nginx 修改service的type为NodePort
$ kubectl expose deployment nginx --port=80 --target-port=80 -type=NodePort 也可以在创建service时指定类型
NodePort: 在ClusterIP基础上为Service在每台机器上绑定一个端口，这样就可以通过NodeIP:NodePort 来访问该服务

kubectl edit svc nginx:

更改完成之后：可以kubectl describe svc nginx 查看type；此时通过kubectl get svc查看服务可以看见外部对应的端口30013；
所有节点的端口查看都可以看见30013；同时也实现了负载均衡：

6.资源清单的书写：

编写文件，编写完成后直接应用即可；

官网参考：https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.18/#deployment-v1-apps

kubectl api-versions ：查询命令
kubectl explain pod 查询帮助文档

kubectl apply -f pod.yml #创建
kubectl delete -f pod.yml #删除

简单资源清单pod的编写示例：

注意：自主式pod清单的修改需要先删除再创建

#pod.yml
apiVersion: v1
kind: Pod
metadata:
  name: nginx
  namespace: default
spec:
  containers:
  - name: nginx
    image: ikubernetes/myapp:v1
    imagePullPolicy: IfNotPresent
1
2
3
4
5
6
7
8
9
10
11

结果：

Deployment控制器示例：

#deployment.yml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  namespace: default
spec:
  replicas: 2
  selector:
    matchLabels:
      run: nginx
  template:
    metadata:
      labels:
        run: nginx
    spec:
      #nodeSelector:
      #  kubernetes.io/hostname: server3
      #nodeName: server3
      #hostNetwork: true
      containers:
      - name: nginx
        image: ikubernetes/myapp:v1
        imagePullPolicy: IfNotPresent
        resources:
          requests:
            cpu: 100m
            memory: 100Mi
          limits:
            cpu: 0.5
            memory: 512Mi

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

结果示例：

7.Pod的生命周期：

pod的状态：

容器的状态：

Waiting （等待）

如果容器并不处在 Running 或 Terminated 状态之一，它就处在 Waiting 状态。 处于 Waiting 状态的容器仍在运行它完成启动所需要的操作：例如，从某个容器镜像 仓库拉取容器镜像，或者向容器应用 Secret 数据等等。 当你使用 kubectl 来查询包含 Waiting 状态的容器的 Pod 时，你也会看到一个 Reason 字段，其中给出了容器处于等待状态的原因。

Running（运行中）

Running 状态表明容器正在执行状态并且没有问题发生。 如果配置了 postStart 回调，那么该回调已经执行且已完成。 如果你使用 kubectl 来查询包含 Running 状态的容器的 Pod 时，你也会看到 关于容器进入 Running 状态的信息。

Terminated（已终止）

处于 Terminated 状态的容器已经开始执行并且或者正常结束或者因为某些原因失败。 如果你使用 kubectl 来查询包含 Terminated 状态的容器的 Pod 时，你会看到 容器进入此状态的原因、退出代码以及容器执行期间的起止时间。

如果容器配置了 preStop 回调，则该回调会在容器进入 Terminated 状态之前执行。

常见的容器探针：

三种探针：

livenessProbe：指示容器是否正在运行。如果存活态探测失败，则 kubelet 会杀死容器， 并且容器将根据其重启策略决定未来。如果容器不提供存活探针， 则默认状态为 Success(成功)。

readinessProbe：指示容器是否准备好为请求提供服务。如果就绪态探测失败， 端点控制器将从与 Pod 匹配的所有服务的端点列表中删除该 Pod 的 IP 地址。 初始延迟之前的就绪态的状态值默认为 Failure。 如果容器不提供就绪态探针，则默认状态为 Success。

startupProbe: 指示容器中的应用是否已经启动。如果提供了启动探针，则所有其他探针都会被 禁用，直到此探针成功为止。如果启动探测失败，kubelet 将杀死容器，而容器依其重启策略进行重启。 如果容器没有提供启动探测，则默认状态为 Success。

livenessProbe探针示例：

#live.yml
apiVersion: v1  #版本
kind: Pod  # 类型
metadata:  #元数据
  labels:  #标签
    test: liveness
  name: liveness-exec
spec:  #资源控制
  containers:
  - name: liveness
    image: busyboxplus
    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
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

#live.yml 
apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-exec
spec:
  containers:
  - name: liveness
    image: myapp:v1
    livenessProbe:
      tcpSocket:
        port: 80
      initialDelaySeconds: 2
      periodSeconds: 3
    readinessProbe:
      httpGet:
        path: /hostname.html
        port: 80
      initialDelaySeconds: 3
      periodSeconds: 3
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

init初始化容器：

# cat service.yml 
---
apiVersion: v1
kind: Service
metadata:
  name: myservice
spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
1
2
3
4
5
6
7
8
9
10
11

#init.yml
apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  containers:
  - name: myapp-container
    image: myapp:v1
  initContainers:
  - name: init-myservice
    image: busyboxplus
    command: ['sh', '-c', "until nslookup myservice.default.svc.cluster.local; do echo waiting for myservice; sleep 2; done"]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

8.k8s中的控制器类型：

8-1：Deployment：

一个 Deployment 为 Pods 和 ReplicaSets 提供声明式的更新能力。

适用于：

创建pod与ReplicaSet
滚动更新和回滚
扩容与缩容
暂停与恢复
1
2
3
4

8-2：ReplicaSet：

可以单独使用，但主要被Deployment用于协调pod创建、删除、更新的机制

ReplicaSet 的目的是维护一组在任何时候都处于运行状态的 Pod 副本的稳定集合。
保证给定数量的、完全相同的 Pod 的可用性。
ReplicaSet 确保任何时间都有指定数量的 Pod 副本在运行（与控制器ReplicationController功能相同）
1
2
3

工作原理

RepicaSet 是通过一组字段来定义的，包括一个用来识别可获得的 Pod 的集合的选择算符、一个用来标明应该维护的副本个数的数值、一个用来指定应该创建新 Pod 以满足副本个数条件时要使用的 Pod 模板等等。 每个 ReplicaSet 都通过根据需要创建和 删除 Pod 以使得副本个数达到期望值， 进而实现其存在价值。当 ReplicaSet 需要创建新的 Pod 时，会使用所提供的 Pod 模板。

ReplicaSet 通过 Pod 上的 metadata.ownerReferences 字段连接到附属 Pod，该字段给出当前对象的属主资源。 ReplicaSet 所获得的 Pod 都在其 ownerReferences 字段中包含了属主 ReplicaSet 的标识信息。正是通过这一连接，ReplicaSet 知道它所维护的 Pod 集合的状态， 并据此计划其操作行为。

ReplicaSet 使用其选择算符来辨识要获得的 Pod 集合。如果某个 Pod 没有 OwnerReference 或者其 OwnerReference 不是一个 控制器，且其匹配到 某 ReplicaSet 的选择算符，则该 Pod 立即被此 ReplicaSet 获得。

rs 示例：

#rs.yml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: myapp:v1
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

8-3：DaemonSet

DaemonSet 确保全部（或者某些）节点上运行一个 Pod 的副本。 当有节点加入集群时， 也会为他们新增一个 Pod 。 当有节点从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod。

DaemonSet 的一些典型用法：

在每个节点上运行集群守护进程
在每个节点上运行日志收集守护进程
在每个节点上运行监控守护进程
1
2
3

一种简单的用法是为每种类型的守护进程在所有的节点上都启动一个 DaemonSet。 一个稍微复杂的用法是为同一种守护进程部署多个 DaemonSet；每个具有不同的标志， 并且对不同硬件类型具有不同的内存、CPU 要求

示例：

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: daemonset-example
  labels:
    k8s-app: zabbix-agent
spec:
  selector:
    matchLabels:
      name: zabbix-agent
  template:
    metadata:
      labels:
        name: zabbix-agent
    spec:
      containers:
      - name: zabbix-agent
        image: zabbix-agent
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

8-4：Job：

Job只执行一次

Job 会创建一个或者多个 Pods，并将继续重试 Pods 的执行，直到指定数量的 Pods 成功终止。 随着 Pods 成功结束，Job 跟踪记录成功完成的 Pods 个数。 当数量达到指定的成功个数阈值时，任务（即 Job）结束。 删除 Job 的操作会清除所创建的全部 Pods。

一种简单的使用场景下，你会创建一个 Job 对象以便以一种可靠的方式运行某 Pod 直到完成。 当第一个 Pod 失败或者被删除（比如因为节点硬件失效或者重启）时，Job 对象会启动一个新的 Pod。

#计算 π 到小数点后 2000 位，并将结果打印出来
apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  template:
    spec:
      containers:
      - name: pi
        image: perl
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never
  backoffLimit: 4
1
2
3
4
5
6
7
8
9
10
11
12
13
14

8-5： Cronjob基于时间调度的job:

#每分钟打印出当前时间和问候消息
apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/1 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busyboxplus
            imagePullPolicy: IfNotPresent
            args:
            - /bin/sh
            - -c
            - date; echo Hello from the Kubernetes cluster
          restartPolicy: OnFailure
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20