7. Kubernetes的资源对象

深藏阁楼爱情的钟 2023-06-17 11:54 24阅读 0赞

在Kubernetes系统中，Kubernetes对象是持久化的实体。Kubernetes使用这些实体去表示整个集群的状态。特别地，它们描述了如下信息：

哪些容器化应用在运行（以及在哪个 Node 上）
    
    可以被应用使用的资源
    
    关于应用运行时表现的策略，比如重启策略、升级策略，以及容错策略

Kubernetes对象是“目标性记录”。一旦创建对象，Kubernetes系统将持续工作以确保对象存在。通过创建对象，本质上是在告知Kubernetes系统，所需要的集群工作负载看起来是什么样子的，这就是Kubernetes集群的期望状态（Desired State）。

每个Kubernetes对象包含两个嵌套的对象字段，它们负责管理对象的配置：`spec`（对象规约）和`status`（对象状态） 。 `spec`是必需的，它描述了对象的期望状态（Desired State）——希望对象所具有的特征。`status`描述了对象的实际状态（Actual State），它是由Kubernetes系统提供和更新的。在任何时刻，Kubernetes控制面一直努力地管理着对象的实际状态以与期望状态相匹配。

*  必需字段：

在想要创建的Kubernetes对象对应的`.yaml`文件中，需要配置如下的字段：

apiVersion - 创建该对象所使用的 Kubernetes API 的版本
    
    kind - 想要创建的对象的类型
    
    metadata - 帮助识别对象唯一性的数据，包括一个 name 字符串、UID 和可选的 namespace

大部分对象也需要提供对象的`spec`字段。`spec`的精确格式对每个Kubernetes对象来说是不同的，包含了特定于该对象的嵌套字段。

--------------------

### 命名空间Namespace ###

命名空间Namespace本质上也是kubernetes的一种资源对象，主要起隔离作用：

资源对象的隔离：Service、Deployment、Pod
    
    资源配额的隔离：CPU、Memory

大多数 kubernetes 资源（例如 Pod、服务、副本控制器等）都位于某些Namespace中。 但是Namespace资源本身并不在Namespace中。

而且底层资源，例如节点和持久化卷不属于任何Namespace。

查看哪些Kubernetes资源在Namespace中，哪些不在Namespace中：

kubectl api-resources --namespaced=true             #资源在Namespace中
    
    kubectl api-resources --namespaced=false                #资源不在Namespace中

*  查看所有namespace：

# kubectl get namespaces
    
    NAME              STATUS   AGE
    default           Active   13d
    ingress-nginx     Active   7d2h
    kube-node-lease   Active   13d
    kube-public       Active   13d
    kube-system       Active   13d

default是默认的Namespace。当创建Service、Deployment、Pod时不指定Namespace，则会创建在default这个Namespace下。

*  创建一个namespace：

# vim namespace-dev.yaml

apiVersion: v1
    kind: Namespace
    metadata:
      name: dev

# kubectl create -f namespace-dev.yaml
    
    # kubectl get namespaces
    
    NAME              STATUS   AGE
    default           Active   13d
    dev               Active   28s
    ingress-nginx     Active   7d2h
    kube-node-lease   Active   13d
    kube-public       Active   13d
    kube-system       Active   13d

*  在dev namespace下创建资源对象：

在yaml文件中对应的资源分别指定Namespace，或创建资源时命令行指定Namespace（`-n namespace`）。

# vim web-dev.yaml

apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: web-demo
      namespace: dev                #指定namespace
    spec:
      selector:
        matchLabels:
          app: web-demo
      replicas: 1
      template:
        metadata:
          labels:
            app: web-demo
        spec:
          containers:
          - name: web-demo
            image: hub.lzxlinux.cn/kubernetes/web:latest
            ports:
            - containerPort: 8080
    ---
    apiVersion: v1
    kind: Service
    metadata:
      name: web-demo
      namespace: dev                #指定namespace
    spec:
      ports:
      - port: 80
        protocol: TCP
        targetPort: 8080
      selector:
        app: web-demo
      type: ClusterIP
    ---
    apiVersion: extensions/v1beta1
    kind: Ingress
    metadata:
      name: web-demo
      namespace: dev                #指定namespace
    spec:
      rules:
      - host: web-dev.lzxlinux.cn
        http:
          paths:
          - path: /
            backend:
              serviceName: web-demo
              servicePort: 80

# kubectl create -f web-dev.yaml
    
    # kubectl get all -n dev
    
    NAME                            READY   STATUS    RESTARTS   AGE
    pod/web-demo-786c69fdf4-wshvj   1/1     Running   0          13s
    
    NAME               TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE
    service/web-demo   ClusterIP   10.104.136.249   <none>        80/TCP    12s
    
    NAME                       READY   UP-TO-DATE   AVAILABLE   AGE
    deployment.apps/web-demo   1/1     1            1           13s
    
    NAME                                  DESIRED   CURRENT   READY   AGE
    replicaset.apps/web-demo-786c69fdf4   1         1         1       13s

在dev Namespace下可以看到刚创建的资源对象。当查看的资源对象在default这个Namespace下时，可以省略`-n default`。

ReplicaSet是隐藏在Deployment下面的一层概念，Deployment使用ReplicaSet来管理Pod，一般建议使用Deployment而不直接使用ReplicaSet。

*  隔离机制：

不同Namespace下Service的ip是可以互相访问的，`CLUSTER-IP`和Namespace无关。而且不同Namespace下Pod的ip也是可以互相访问的。

这说明Namespace的隔离是基于名称来隔离的，并不是物理的隔离。资源的名称在Namespace内是惟一的，且不能跨Namespace。Namespace不能嵌套在另一个Namespace内，而且每个Kubernetes资源只能属于一个Namespace。

*  namespace划分：

按环境划分：dev、test
    
    按团队划分
    
    自定义多级划分

--------------------

### 资源Resources ###

资源Resources包含：

CPU
    
    Memory
    
    GPU
    
    持久化存储

*  核心设计：

Requests    最低要求
    
    Limits      最高限制

*  配置一个resources：

# vim web-dev.yaml

apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: web-demo
      namespace: dev
    spec:
      selector:
        matchLabels:
          app: web-demo
      replicas: 1
      template:
        metadata:
          labels:
            app: web-demo
        spec:
          containers:
          - name: web-demo
            image: hub.lzxlinux.cn/kubernetes/web:latest
            ports:
            - containerPort: 8080
            resources:              #配置resources，1000m为1个cpu，100Mi为100M内存
              requests:
                memory: 100Mi
                cpu: 100m
              limits:
                memory: 100Mi
                cpu: 200m
    ---
    apiVersion: v1
    kind: Service
    metadata:
      name: web-demo
      namespace: dev
    spec:
      ports:
      - port: 80
        protocol: TCP
        targetPort: 8080
      selector:
        app: web-demo
      type: ClusterIP
    ---
    apiVersion: extensions/v1beta1
    kind: Ingress
    metadata:
      name: web-demo
      namespace: dev
    spec:
      rules:
      - host: web-dev.lzxlinux.cn
        http:
          paths:
          - path: /
            backend:
              serviceName: web-demo
              servicePort: 80

# kubectl apply -f web-dev.yaml
    
    # kubectl describe pod web-demo-67445bf664-5ggtc -n dev #返回信息包含resources相关配置 
    
        Limits:
          cpu:     200m
          memory:  100Mi
        Requests:
          cpu:        100m
          memory:     100Mi
    
    # kubectl describe nodes node1 #查看node1的资源已使用情况
    
      Resource           Requests    Limits
      --------           --------    ------
      cpu                400m (20%)  300m (15%)
      memory             200Mi (5%)  400Mi (10%)
      ephemeral-storage  0 (0%)      0 (0%)

*  服务可靠性：

Requests = Limits   可靠性最高，优先级最高
    
    Limits > Requests   可靠性适中，优先级适中
    
    不设置Resources     可靠性最低，优先级最低，不建议

当资源紧张时，优先级最低的服务进程会优先被杀死。

*  创建一个LimitRange：

LimitRange是基于Namespace的资源管理，对cpu和memory使用范围进行限制。

# vim limits-test.yaml

apiVersion: v1
    kind: LimitRange
    metadata:
      name: test-limits
    spec:
      limits:
      - max:
          cpu: 4000m
          memory: 2Gi
        min:
          cpu: 100m
          memory: 100Mi
        maxLimitRequestRatio:               #Limit与Request的比值限制
          cpu: 3
          memory: 2
        type: Pod               #对pod限制
      - default:                #Limit默认值
          cpu: 300m
          memory: 200Mi
        defaultRequest:
          cpu: 200m
          memory: 100Mi
        max:
          cpu: 2000m
          memory: 1Gi
        min:
          cpu: 100m
          memory: 100Mi
        maxLimitRequestRatio:
          cpu: 5
          memory: 4
        type: Container             #对container限制

Pod的Resources不能有默认值，它是逻辑概念，表示一组container，并不存在默认值。

# kubectl apply -f limits-test.yaml -n dev
    
    # kubectl get limitranges -n dev
    
    NAME          CREATED AT
    test-limits   2019-11-27T08:23:42Z
    
    # kubectl describe limitranges test-limits -n dev
    
    Name:       test-limits
    Namespace:  dev
    Type        Resource  Min    Max  Default Request  Default Limit  Max Limit/Request Ratio
    ----        --------  ---    ---  ---------------  -------------  -----------------------
    Pod         cpu       100m   4    -                -              3
    Pod         memory    100Mi  2Gi  -                -              2
    Container   cpu       100m   2    200m             300m           5
    Container   memory    100Mi  1Gi  100Mi            200Mi          4

当配置了LimitRange后，如果在创建Deployment时不符合限制要求，则不会根据Deployment创建Pod，Deployment也不可用。

*  创建一个ResourceQuota：

ResourceQuota可以对Namespace进行资源的限制。

# vim compute-resource.yaml

apiVersion: v1
    kind: ResourceQuota
    metadata:
      name: resource-quota
    spec:
      hard:
        pods: 4
        requests.cpu: 2000m
        requests.memory: 4Gi
        limits.cpu: 4000m
        limits.memory: 8Gi
        configmaps: 10
        persistentvolumeclaims: 4
        replicationcontrollers: 20
        secrets: 10
        services: 10

# kubectl apply -f compute-resource.yaml -n dev
    
    # kubectl get resourcequotas -n dev
    
    NAME             CREATED AT
    resource-quota   2019-11-27T08:38:40Z
    
    # kubectl describe resourcequotas resource-quota -n dev
    
    Name:                   resource-quota
    Namespace:              dev
    Resource                Used   Hard
    --------                ----   ----
    configmaps              0      10
    limits.cpu              200m   4
    limits.memory           100Mi  8Gi
    persistentvolumeclaims  0      4
    pods                    1      4
    replicationcontrollers  0      20
    requests.cpu            100m   2
    requests.memory         100Mi  4Gi
    secrets                 1      10
    services                1      10

通过ResourceQuota可以限制Namespace下各类资源对象的数量及配额。

当Namespace下的某个资源对象达到限制时，无法创建新的资源对象，如pod限制数为4，但副本数为5，因此最大数量为4，最后1个无法创建。

*  Pod驱逐策略——Eviction：

常见驱逐策略配置：

--eviction-soft=memory.available<1.5Gi
    --eviction-soft-grace-period=memory.available=1m30s             #满足所有soft条件驱逐
    
    --eviction-hard=memory.available<100Mi,
    nodefs.available<1Gi,nodefs.inodesFree<5%               #满足任一条件立即驱逐

磁盘紧缺时：

1. 删除死掉的pod、容器
    
    2. 删除无用的镜像
    
    3. 按优先级、资源占用情况驱逐pod

内存紧缺时：

1. 驱逐不可靠的pod
    
    2. 驱逐基本可靠的pod
    
    3. 驱逐可靠的pod

驱逐策略的合理配置有利于保证kubernetes集群的稳定性。

--------------------

### 标签Label ###

标签Label本质上是附加到资源对象(如Pod)上的键值对（key-value）。Label可以“贴”在各种资源对象上，如Pod、Deployment、Service、Node等。相同的Label可以“贴”在不同的资源对象上，一个资源对象也可以有任意多个不同的Label。

Label用于指定对象的标识属性，这些属性对用户来说是有意义的和相关的。Label可以在创建时附加到对象上，然后在任何时候添加和修改。 每个对象都可以定义一组Label。但每个Label的Key必须是唯一的。

与名称和uid不同，标签不提供唯一性。通常，我们希望许多对象都带有相同的标签，通过标签选择器`selector`，客户机或用户可以识别一组资源对象。

*  示例：

apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: web-demo
      namespace: dev
    spec:
      selector:
        matchLabels:
          app: web-demo             #指定Label，必须与template的Label相同
      replicas: 1
      template:
        metadata:
          labels:
            app: web-demo               #指定Label
        spec:
          containers:
          - name: web-demo
            image: hub.lzxlinux.cn/kubernetes/web:latest
            ports:
            - containerPort: 8080
    ---
    apiVersion: v1
    kind: Service
    metadata:
      name: web-demo
      namespace: dev
    spec:
      ports:
      - port: 80
        protocol: TCP
        targetPort: 8080
      selector:
        app: web-demo               #指定Label，需要与template的Label相同
      type: ClusterIP
    ---
    apiVersion: extensions/v1beta1
    kind: Ingress
    metadata:
      name: web-demo
      namespace: dev
    spec:
      rules:
      - host: web-dev.lzxlinux.cn
        http:
          paths:
          - path: /
            backend:
              serviceName: web-demo
              servicePort: 80

对于Deployment来说，`selector`的Label必须与`template`中的Label一致，这样才能根据`template`创建一组Pod，这一组Pod组成一个Deployment。

对于Service来说，`selector`的Label匹配的是具有相同Label的Pod，跟Deployment无关。如果两个Deployment代表的Pod的Label相同，则Service会轮询这两个Deployment。

*  给node设置label：

# kubectl label nodes node1 role=54
    
    # kubectl get nodes --show-labels |grep node1
    
    node1     Ready    <none>   14d   v1.14.0   app=ingress,beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=node1,kubernetes.io/os=linux,role=54

可以看到刚刚设置的Label。当给Deployment设置`nodeSelector`，如果不能匹配到对应Label的node，则该Deployment无法创建。

# vim deploy-dev.yaml

apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: web-test
      namespace: dev
    spec:
      selector:
        matchLabels:
          app: web-test
      replicas: 1
      template:
        metadata:
          labels:
            app: web-test
        spec:
          containers:
          - name: web-test
            image: hub.lzxlinux.cn/kubernetes/web:latest
            ports:
            - containerPort: 8080
          nodeSelector:             #选择对应Label
            role: "55"

# kubectl apply -f deploy-dev.yaml -n dev
    
    # kubectl get deploy -n dev
    
    NAME       READY   UP-TO-DATE   AVAILABLE   AGE
    web-demo   1/1     1            1           142m
    web-test   0/1     1            0           7s
    
    # kubectl get pod -n dev
    
    NAME                        READY   STATUS    RESTARTS   AGE
    web-demo-67445bf664-5ggtc   1/1     Running   0          114m
    web-test-bc777d99f-v5w4x    0/1     Pending   0          11s
    
    # kubectl describe pod web-test-bc777d99f-v5w4x -n dev
    
    Events:
      Type     Reason            Age   From               Message
      ----     ------            ----  ----               -------
      Warning  FailedScheduling  43s   default-scheduler  0/6 nodes are available: 6 node(s) didn't match node selector.

可以看到，因为没有对应Label的node节点，所以调度失败，pod一直处于pending状态。

# kubectl label nodes node1 role=55 --overwrite
    
    # kubectl get deploy -n dev
    NAME       READY   UP-TO-DATE   AVAILABLE   AGE
    web-demo   1/1     1            1           145m
    web-test   1/1     1            1           20s
    
    # kubectl get pod -o wide -n dev 
    NAME                        READY   STATUS    RESTARTS   AGE     IP             NODE    NOMINATED NODE   READINESS GATES
    web-demo-67445bf664-5ggtc   1/1     Running   0          118m    172.10.4.98    node1   <none>           <none>
    web-test-bc777d99f-v5w4x    1/1     Running   0          25s     172.10.4.100   node1   <none>           <none>

在更改完node的Label后，pod在node1节点成功运行。

*  标签过滤：

基于等式或不等式的需求允许通过标签键和值进行过滤。 匹配对象必须满足所有指定的标签约束。 支持三种操作符：`=`、`==`和`!=` 前两个表示相等，最后表示不相等。 例如:

environment = production
    tier != frontend

基于集合的标签需求允许根据一组值设置过滤键。 支持三种操作符: `in`、`notin`和`exists`。 例如:

environment in (production, qa)
    tier notin (frontend, backend)
    partition
    !partition

基于集合的需求可以与基于等式的需求结合起来过滤。

*  共享标签：

共享标签和注解都使用同一个前缀：`app.kubernetes.io`。没有前缀的标签是用户私有的。共享前缀可以确保共享标签不会干扰用户自定义的标签。

为了充分利用这些标签，应该在每个资源对象上都使用它们。

<table> 
 <thead> 
  <tr> 
   <th align="center">键</th> 
   <th align="center">描述</th> 
   <th align="center">示例</th> 
   <th align="center">类型</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td align="center">app.kubernetes.io/name</td> 
   <td align="center">应用程序的名称</td> 
   <td align="center">mysql</td> 
   <td align="center">字符串</td> 
  </tr> 
  <tr> 
   <td align="center">app.kubernetes.io/instance</td> 
   <td align="center">用于唯一确定应用实例的名称</td> 
   <td align="center">wordpress-abcxzy</td> 
   <td align="center">字符串</td> 
  </tr> 
  <tr> 
   <td align="center">app.kubernetes.io/version</td> 
   <td align="center">应用程序的当前版本（例如，语义版本，修订版哈希等）</td> 
   <td align="center">5.7.21</td> 
   <td align="center">字符串</td> 
  </tr> 
  <tr> 
   <td align="center">app.kubernetes.io/component</td> 
   <td align="center">架构中的组件</td> 
   <td align="center">database</td> 
   <td align="center">字符串</td> 
  </tr> 
  <tr> 
   <td align="center">app.kubernetes.io/part-of</td> 
   <td align="center">此级别的更高级别应用程序的名称</td> 
   <td align="center">wordpress</td> 
   <td align="center">字符串</td> 
  </tr> 
  <tr> 
   <td align="center">app.kubernetes.io/managed-by</td> 
   <td align="center">用于管理应用程序的工具</td> 
   <td align="center">helm</td> 
   <td align="center">字符串</td> 
  </tr> 
 </tbody> 
</table>

示例：

apiVersion: apps/v1
    kind: StatefulSet
    metadata:
      labels:
        app.kubernetes.io/name: mysql
        app.kubernetes.io/instance: wordpress-abcxzy
        app.kubernetes.io/version: "5.7.21"
        app.kubernetes.io/component: database
        app.kubernetes.io/part-of: wordpress
        app.kubernetes.io/managed-by: helm

--------------------