pod资源理论及service部分知识

目录

Pod资源的理论讲解：

一，标签

什么是标签？

1，给pod资源打标签

查看资源标签

2，node节点选择器

nodeName:指定pod节点运行在哪个具体node上。

3，pod节点亲和性

4，pod节点反亲和性

Pod常见的状态和重启策略

常见的pod状态

2，Pod重启策略

3，存货性探测livenessProbe和就绪性探测readinessProbe：

1，Livenessprobe：存活性探测

2，ReadinessProbe：就绪性探测

二，四层负载均衡service：

为什么要有service？

---

Pod资源的理论讲解：

一，标签

什么是标签？

标签其实就是一对key/value，被关联到对象上，比如pod，标签的使用我们倾向于能够表示对象的特殊特点，就是一眼就看出了这个pod是干什么的，标签可以用来划分特定的对象（比如版本，服务类型），标签可以在创建一个对象的时候直接定义，也可以在后期随时修改，每一个对象可以拥有多个标签，但是，key值必须是唯一的，创建标签之后也可以方便我们对资源进行分组管理，如果对pod打标签，之后就可以使用标签来查看，删除指定的pod，在k8s中，大部分资源都可以打标签。

1，给pod资源打标签

对已经存在的资源打标签：kubectl label pods pod-first release=v1

查看标签是否打成功：kubectl getpods pod-first --show-labels

查看资源标签

查看默认名称空间下的所有pod资源的标签：kubectl get pods --show-labels

查看默认名称空间下指定pod具有的所有标签：kubectl get pods pod-first --show-labels

列出默认名称空间下标签key是release的pod，不显示标签：kubectl get pods -l release

列出默认名称空间下标签key是release，值是v1的pod，不显示标签：kubectl get pods -l release=v1

列出默认名称空间下标签key是release的所有的pod，并打印对应的标签值：kubectl get pods -L release

查看所有名称空间下的所有的pod的标签：kubectl get pods --all-namespace --show-labels

2，node节点选择器

nodeName:指定pod节点运行在哪个具体node上。

例如将创建的新pod资源运行在第二个node节点上：

Vim pod-node.yaml

apiVersion: v1

kind: Pod

metadata:

  name: demo-pod1

  namespace: default

  labels:

    app: myapp

    env: dev

spec:

  nodeName: hd2.com

  containers:

  - name:  tomcat-pod-java

    ports:

    - containerPort: 8080

    image: tomcat:8.5-jre8-alpine

    imagePullPolicy: IfNotPresent

  - name: busybox

    image: busybox:1.28

    command:

    - "/bin/sh"

    - "-c"

- "sleep 3600"

3，pod节点亲和性

pod自身的亲和性调度有两种表示形式：

Podaffinity：pod和pod更倾向腻在一起，，把相近的pod结合到相近的的位置

Pod节点亲和性：定义两个pod，第一个pod做为基准，第二个pod跟着它走

Vim required-affinity-demo.yam

apiVersion: v1

kind: Pod

metadata:

  name: pod-first

  labels:

    app2: myapp2

    tier: frontend

spec:

  containers:

  - name: myapp

    image: ikubernetes/myapp:v1

    imagePullPolicy: IfNotPresent

---

apiVersion: v1

kind: Pod

metadata:

  name: pod-second

  labels:

    app: backend

    tier: db

spec:

  containers:

  - name: busybox

    image: busybox:1.28

    imagePullPolicy: IfNotPresent

    command: ["sh","-c","sleep 3600"]

  affinity:

    podAffinity:

      requiredDuringSchedulingIgnoredDuringExecution:

      - labelSelector:

          matchExpressions:

          - {key: app2, operator: In, values: ["myapp2"]}

        topologyKey: kubernetes.io/hostname

 

4，pod节点反亲和性

定义两个pod，第一个pod作为基准，第二个pod跟它调度节点相反

Vim required-anti-affinity-demo.yaml

apiVersion: v1

kind: Pod

metadata:

  name: pod-first

  labels:

    app1: myapp1

    tier: frontend

spec:

    containers:

    - name: myapp

      image: ikubernetes/myapp:v1

---

apiVersion: v1

kind: Pod

metadata:

  name: pod-second

  labels:

    app: backend

    tier: db

spec:

    containers:

    - name: busybox

      image: busybox:1.28

      imagePullPolicy: IfNotPresent

      command: ["sh","-c","sleep 3600"]

    affinity:

      podAntiAffinity:

         requiredDuringSchedulingIgnoredDuringExecution:

         - labelSelector:

              matchExpressions:

              - {key: app1, operator: In, values: ["myapp1"]}

           topologyKey: kubernetes.io/hostname

 

Pod常见的状态和重启策略

1. 常见的pod状态

挂起：（pending）：我们在请求创建pod时，条件不满足，调度没有完成，没有任何一个节点能满足调度条件已经创建的pod但是没有适合它运行的节点就叫做挂起，调度没有完成，处于pending的状态会持续一段时间，包括调度pod的时间和通过网络下载镜像的时间。

运行中（running）：pod已经绑定到了一个节点上，pod中所有的容器都已经被创建，至少有一个容器正在运行。

成功（succeeded）：pod中的所有容器都被成功终止，并且不会再重启。

失败（failed）：pod中的所有容器都已经终止，并且至少有一个容器是因为失败终止，也就是说，容器以非0状态退出或者被系统终止。

未知（unknown）：未知状态，所谓pod是什么状态是apiserver和运行再pod节点的kubelet进行通信获取状态信息的，如果节点之上的kubelet本身出故障没那么apiserver就连不上kubelet，得不到信息了，就会看unknown

2，Pod重启策略

Pod的重启策略应用与pod内的所有容器，并且仅在pod所处的node上由kubelet进行判断和重启操作，当某个容器异常退出或者健康检查失败时，kubelet将根据RestartPolicy的设置来进行相应的操作。

Pod的重启策略包括：Always，OnFailure和Never，默认值为Always

Always：当容器失败时，由kubelet自动重启该容器。

OnFailure：当容器终止与逆行且退出码不为0时，由kubelet自动重启该容器。

Never：不论容器运行状态如何，kubelet都不会重启该容器。

3，存货性探测livenessProbe和就绪性探测readinessProbe：

1，Livenessprobe：存活性探测

许多应用程序经过长时间运行，最终度过无法运行的状态，除了重启，无法恢复，通常情况下，k8s会发现应用程序已经终止，然后重启应用程序pod。

2，ReadinessProbe：就绪性探测

再没有配置redinessProbe的资源对象中，pod中的容器完成后，就认为pod中的应用程序可以对外提供服务，该pod就会加入相应的service对外提供服务。

目前LivenesProbe和ReadinessProbe两种探针都支持下面三种探测方法：

ExecAction：在容器中执行指定的命令，如果执行成功，退出码为0则探测成功。

TCPSocketAction：通过容器的ip地址和端口号执行TCP检查，如果能够建立TCP连接，则表明容器健康。

HTTPGetAction：通过容器的IP地址，端口号及路径调用HTTP Get方法，如果响应的状态码大于200且小于400，则认为容器健康探针探测结果有以下值：

Success：表示通过检测。、

Failure：表示未通过检测。

Unknown：表示检测没有正常进行。

二，四层负载均衡service：

为什么要有service？

在kubernetes中pod是有声明周期的，如果pod重启它的IP很可能会发生变化，如果我们的服务都是将pod的地址写死，pod挂掉或者重启，和刚才重启的pod相关的其他服务将会找不到它所关联的pod，为了解决这个问题，所以定义了service资源对象，service定义i了一个服务访问的入口，客户端通过这个入口即可访问服务背后的应用集群实例，service是一组pod的逻辑集合，这一组pod能够被service访问到，通常是通过Label selector实现的。

Pod ip经常发生变化，service是pod的代理，我们的客户端访问，只需要访问service，就会把请求代理到pod

Pod IP在k8s集群之外无法访问，所以需要创建service，这个service可以在k8s集群访问的。