Kubernetes Pod的资源浅析（二）

长安故里

已于 2022-04-27 11:48:40 修改

阅读量363

点赞数 2

分类专栏： Kubernetes 文章标签： linux 运维 kubernetes

于 2020-05-13 16:47:40 首次发布

本文链接：https://blog.csdn.net/lsx_3/article/details/105998840

版权

Kubernetes 专栏收录该内容

12 篇文章 2 订阅

订阅专栏

Kubernetes Pod的资源浅析（二）

Pod的资源管理（resources）
1.资源管理可以限制请求资源的最大值，如CPU的使用量或者内存的使用量
2.requests未设置时，默认与limits相同。
3.limits未设置时，默认值与集群配置相关。
4.可以使用requests来设置各容器需要的最小资源
5.limits用于限制运行时容器占用的资源，用来限制容器的最大CPU、内存的使用率。
6.当容器申请内存超过limits时会被终止，并根据重启策略进行重启。.
使用示例：

	spec:
	  containers:
	  - name: tomcat
	    image: tomcat
	    ports:
	    - containerPort: 8080
	    resources:
	      requests:
	        cpu: "500m"
	        memory: "512Mi"
	      limits:
	        cpu: 0.1
	        memory: 100Mi

生命周期管理（lifecycle）

创建资源对象时，可以使用lifecycle来管理容器在运行前和关闭前的一些动作

lifecycle有两种回调函数

postStart：容器创建成功后，运行前的任务，用于资源部署、环境准备等
使用示例：

spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 80
    lifecycle:
     #（exec/httpGet/tcpSocket）
      postStart:
        exec:
          command: ["/bin/bash", "-c", "echo Hello from the postStart handler > /usr/share/message"]

preStop：在容器被终止前的任务，用于优雅关闭应用程序、通知其他系统等等。

spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 80
    lifecycle:
      #（exec/httpGet/tcpSocket）
      preStop:
      # 结束之前运行一条http请求
        httpGet:
          host: 192.168.1.1
          path: api/v2/devops/pkg/upload_hooks
          prot: 8080

初始化容器（Init Container）

在K8S的Pod中，有两类容器，一类是系统容器（PodContainer），一类是用户容器（User Container），在用户容器中，现在又分成两类容器，一类是初始化容器（Init Container），一类是应用容器（App Container）。

Init Container就是做初始化工作的容器。可以有一个或多个，如果多个按照定义的顺序依次执行，只有所有的执行完后，主容器才启动。由于一个Pod里的存储卷是共享的，所以Init Container里产生的数据可以被主容器使用到。

Init Container可以在多种K8S资源里被使用到如Deployment、DaemonSet, StatefulSet、Job等，但都是在Pod启动时，在主容器启动前执行，做初始化工作。
使用示例：
```
 spec:
   containers:
   - name: busybox
     image: busybox
     command: ["sh", "-c", "echo The app is running ! && sleep 3600"]
   initContainers:
   - name: init-myservice
     image: busybox
     command: ["sh", "-c", "until nslook myservice; do echo waiting for myservice; sleep 2; done;"]
   - name: init-mydb
     image: busybox
     command: ["sh", "-c", "until nslook mydb; do echo waiting for mydb; sleep 2; done;"]
```
nodeSelector

通过kubernetes的label-selector机制进行节点选择，由scheduler调度策略MatchNodeSelector进行label匹配，调度pod到目标节点，该匹配规则是强制约束。
使用示例：
```
spec:
  nodeSelector:
    kubernetes.io/hostname: oss-centos76-2
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 80
```

亲和性（affinity）

Affinity 翻译成中文是“亲和性”，它对应的是 Anti-Affinity，我们翻译成“互斥”。这两个词比较形象，可以把 pod 选择 node 的过程类比成磁铁的吸引和互斥，不同的是除了简单的正负极之外，pod 和 node 的吸引和互斥是可以灵活配置的。
Affinity的优点：

匹配有更多的逻辑组合，不只是字符串的完全相等。
调度分成软策略(soft)和硬策略(hard)，在软策略下，如果没有满足调度条件的节点，pod会忽略这条规则，继续完成调度。

目前主要的node affinity：

requiredDuringSchedulingIgnoredDuringExecution
表示pod必须部署到满足条件的节点上，如果没有满足条件的节点，就不停重试。其中IgnoreDuringExecution表示pod部署之后运行的时候，如果节点标签发生了变化，不再满足pod指定的条件，pod也会继续运行。
requiredDuringSchedulingRequiredDuringExecution
表示pod必须部署到满足条件的节点上，如果没有满足条件的节点，就不停重试。其中RequiredDuringExecution表示pod部署之后运行的时候，如果节点标签发生了变化，不再满足pod指定的条件，则重新选择符合要求的节点。
preferredDuringSchedulingIgnoredDuringExecution
表示优先部署到满足条件的节点上，如果没有满足条件的节点，就忽略这些条件，按照正常逻辑部署。
preferredDuringSchedulingRequiredDuringExecution
表示优先部署到满足条件的节点上，如果没有满足条件的节点，就忽略这些条件，按照正常逻辑部署。其中RequiredDuringExecution表示如果后面节点标签发生了变化，满足了条件，则重新调度到满足条件的节点。

nodeAffinity使用示例

spec:
  affinity:
    nodeAffinity:
      # 要求 pod 运行在特定 AZ 的节点上
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/e2e-az-name
            operator: In
            values:
            - e2e-az1
            - e2e-az2
      # 希望节点最好有对应的 another-node-label-key:another-node-label-value 标签
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: another-node-label-key
            operator: In
            #这里的匹配逻辑是label在某个列表中，可选的操作符有：
            #In: label的值在某个列表中
            #NotIn：label的值不在某个列表中
            #Exists：某个label存在
            #DoesNotExist：某个label不存在
            #Gt：label的值大于某个值（字符串比较）
            #Lt：label的值小于某个值（字符串比较）
            values:
            - another-node-label-value
  containers:
  - name: with-node-affinity
    image: nginx
    ports:
    - containerPort: 80
      hostPort: 80

node affinity和node affinity大同小异，概念都差不多，就不用赘诉
podeAffinity使用示例

spec:
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution: #硬亲和，必须满足
      - labelSelector:
          matchExpressions:
          - key: security
            operator: In
            values:
            - S1           #value的列表
        topologyKey: kubernetes.io/hostname  #通过node的hostname判断是否是相同节点，节点名一定不能一样
  containers:
  - name: with-node-affinity
    image: nginx
    ports:
    - containerPort: 80
      hostPort: 80

podeAffinity（反亲和）使用示例

spec:
  affinity:
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution: #软亲和
      - weight: 100 #权重
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: security
              operator: In
              values:
              - S2   #pod label security=s2,则不能调度
          topologyKey: kubernetes.io/hostname #通过node的hostname判断是否是相同节点，节点名一定不能一样

活跃时长（activeDeadlineSeconds）

控制Pod最长活跃时间
使用示例

spec:
  activeDeadlineSeconds: 30 #最长活跃时间30s
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 80
      hostPort: 80

DNS配置（dnsConfig）
- 在 kubernetes 中将 DNS 设置配置在 dnsConfig 配置项中，而 dnsConfig 包含在 PodSpec 配置项中，因此 Pod 内所有容器都共享相同的 Network Namespace 。
- 在 kubernetes 中还提供了 dnsPolicy 决定 Pod 内预设 DNS 配置策略：
  - None （无任何策略）
    清除 Pod 预设 DNS 配置，当 dnsPolicy 设置成为这个值之后， kubernetes 不会为 Pod 预先加载任何逻辑用于判定得到 DNS 的配置。
  - Default （默认）
    Pod 里面的 DNS 配置继承了宿主机上的 DNS 配置。
  - ClusterFirst （集群 DNS 优先）
    与 Default 相反，会预先使用 kube-dns (或 CoreDNS ) 的信息当预设置参数写入到该 Pod 内的DNS配置。
  - ClusterFirstWithHostNet（集群 DNS 优先）
    同时使用 hostNetwork 与 kube-dns 作为 Pod 预设 DNS 配置。
  使用示例：
```
	spec:
	  containers:
	  - name: test
	    image: busybox
	    args:
	    - "sh"
	    - "-c"
	    - "sleep 3600"
	  dnsPolicy: "None"
	  dnsConfig:
	    nameservers:
	    - 114.114.115.115
	    searches:
	    - ns1.svc.cluster.local
	    - my.dns.search.suffix
	    options:
	    - name: ndots
	      value: "2"
	    - name: edns0
```

hostAliases

设定Pod中的hosts文件

spec:
  restartPolicy: Never
  hostAliases:
  - ip: "127.0.0.1"
    hostnames:
    - "foo.local"
    - "bar.local"
  - ip: "10.1.2.3"
    hostnames:
    - "foo.remote"
    - "bar.remote"
  containers:
  - name: nginx
    image: nginx
    command:
    - cat
    args:
    - "/etc/hosts"

hostname

设定Pod的hostname

spec:
  restartPolicy: Never
  hostname: mark
  containers:
  - name: nginx
    image: nginx
    command:
    - hostname

nodeName

用于强制约束将Pod调度到指定的Node节点上，这里说是“调度”，但其实指定了nodeName的Pod会直接跳过Scheduler的调度逻辑，直接写入PodList列表，该匹配规则是强制匹配。
```
spec:
  restartPolicy: Never
  nodeName: oss-centos76-2
  containers:
  - name: nginx
    image: nginx
```

preemptionPolicy

设定pod抢占资源
使用示例

spec:
  restartPolicy: Never
  preemptionPolicy: preemptLowerPriority
  containers:
  - name: nginx
    image: nginx

priority

配置pod的优先级
在配置优先级时，需要先创建相关的资源priorityClassName
high-prioroty.yml

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 1000000
globalDefault: false
description: "This priority class should be used for xxxx service pods only"

使用示例：

spec:
  restartPolicy: Never
  priorityClassName: high-priority
  containers:
  - name: nginx
    image: nginx

结果示例：

Name:                 nginx
Namespace:            default
Priority:             1000000
Priority Class Name:  high-priority

以上为常用的部分Pod资源简介以及示例，后续敬请期待

长安故里

关注

2
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
Kubernetes Pod的资源浅析（二）

Kubernetes Pod的资源浅析（二）Pod的资源管理（resources）1.资源管理可以限制请求资源的最大值，如CPU的使用量或者内存的使用量2.requests未设置时，默认与limits相同。3.limits未设置时，默认值与集群配置相关。4.可以使用requests来设置各容器需要的最小资源5.limits用于限制运行时容器占用的资源，用来限制容器的最大CPU、内存的使用率。6.当容器申请内存超过limits时会被终止，并根据重启策略进行重启。.使用示例： spec:
复制链接

扫一扫