6 篇文章带有标签 “labels”

Node

标签信息

查看单个节点

$ kubectl get node ln1 -o=jsonpath='{.metadata.labels}{"\n"}'
map[beta.kubernetes.io/arch:amd64 beta.kubernetes.io/os:linux kubernetes.io/arch:amd64 kubernetes.io/hostname:ln1 kubernetes.io/os:linux node-role.kubernetes.io/master:]

查看集群所有节点 $ kubectl get nodes -o=jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.metadata.labels}{"\n"}{end}' gpu1 map[beta.kubernetes.io/arch:amd64 beta.kubernetes.io/os:linux k8s.amazonaws.com/accelerator:vgpu kubernetes.io/arch:amd64 kubernetes.io/hostname:gpu1 kubernetes.

节点亲和性（nodeAffinity）

实现 nodeSelector 一样的功能

编写 YAML 文件（kubia.yaml）

apiVersion: apps/v1
kind: Deployment
metadata:
  name: kubia
  labels:
    app: kubia
spec:
  selector:
    matchLabels:
      app: kubia
  replicas: 4
  template:
    metadata:
      labels:
        app: kubia
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: node-type
                operator: In
                values:
                - inference
      containers:
      - name: kubia
        image: wangjunjian/kubia:latest
        ports:
        - containerPort: 8080

• requiredDuringSchedulingIgnoredDuringExecution 必须
• preferredDuringSchedulingIgnoredDuringExecution 优先

污点

通过给节点添加污点，可以拒绝 Pod 调度到节点上。

污点样式

<key>=[value]:<effect>

• value 可以为空
• effect
  • NoSchedule, Pod 必须添加容忍度才能调度到这个节点。
  • PreferNoSchedule, 没有可调度的节点，Pod 会调度到这个节点。（宽松版 NoSchedule）
  • NoExecute, 不仅影响调度，也影响运行的 Pod，没有这个污点容忍度的运行 Pod 都会从这个节点删除。

例子

dedicated=foo:PreferNoSchedule
node-role.kubernetes.io/master:NoSchedule
node.kubernetes.io/unreachable:NoExecute
node.kubernetes.io/unreachable:NoSchedule

增加

kubectl taint node ln6 key1=value1:NoSchedule
# 增加多个
kubectl taint node ln6 key1=value1:NoSchedule key1=value1:PreferNoSchedule

一个 key 可以有多个 effect

删除 kubectl taint node ln6 key1=value1:NoSchedule- # 使用 key

DaemonSet

确保每个节点运行一个 Pod。

使用场景

• 日志收集
• 资源监控
• 网络代理

编写 DaemonSet 的YAML文件（kubia-ds.yaml）

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: kubia
spec:
  selector:
    matchLabels:
      app: kubia
  template:
    metadata:
      labels:
        app: kubia 
    spec:
      containers:
      - name: kubia 
        image: wangjunjian/kubia:latest 
        ports:
        - containerPort: 8080

创建 DaemonSet 对象

$ kubectl apply -f kubia-ds.yaml 
daemonset.apps/kubia created

查看 DaemonSet 对象

ds 是 DaemonSet 的缩写

$ kubectl get ds
NAME    DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
kubia   3         3         2       3            2           <none>          22s

查看 Pod 对象 $ kubectl get pods -o wide NAME READY STATUS RESTARTS

ReplicationController

保证 Pod 对象始终处于期望的运行状态。不管 Pod 因何种原因消失（节点从集群消失或pod从节点中逐出）。

控制器的协调流程

LOOP

1. 通过标签选择器匹配 Pod
2. 比较匹配的数量与期望的副本数量

• 少了。使用当前的模板创建 Pod
• 多了。删除超出数量的 Pod
• 等于。

ReplicationController 的三个主要部分

• selector, 标签选择器
• replicas, 副本个数
• template, Pod 模板

编写 ReplicationController 的YAML文件（kubia-rc.yaml） apiVersion: v1 kind: ReplicationController metadata: name: kubia spec: selector: app: kubia replicas: 2 template: metadata: labels: app: kubia spec: containers: - name: kubia image: wangjunjian/kubia:latest ports: - containerPort: 8080 ★ 可以不指定标签选择器（selector），它会自动根据 Pod 模板中的标签设置。

标签

标签是键值对的形式，用于组织 Kubernetes 资源，为对象进行分组。只要标签的 key 在资源内是唯一的，一个资源便可以拥有多个标签。

通过添加两个标签将 Pod 组织为两个维度（基于应用的横向维度和基于版本的纵向维度）

编写带标签的 Pod YAML文件(kubia-manual-labels.yaml)

apiVersion: v1
kind: Pod
metadata:
  name: kubia-manual-v2
  labels:
    app: sc
    rel: stable
spec:
  containers:
  - image: wangjunjian/kubia
    name: kubia
    ports:
    - containerPort: 8080
      protocol: TCP

创建带标签的 Pod

$ kubectl apply -f kubia-manual-labels.yaml
pod/kubia-manual-v2 created

查看 Pod 的标签（--show-labels） $ kubectl get pods --show-labels NAME READY STATUS RESTARTS AGE LABELS kubia-864465c9d-744qc 1/1 Running 0 5d3h app=kubia,pod-template-hash=864465c9d