Kubernetes中的容器标签

时间:2018-12-28 22:21:13

标签: docker kubernetes

我正在使用jenkins构建我的docker镜像:

docker build --build-arg VCS_REF=$GIT_COMMIT \
--build-arg BUILD_DATE=`date -u +"%Y-%m-%dT%H:%M:%SZ"` \
--build-arg BUILD_NUMBER=$BUILD_NUMBER -t $IMAGE_NAME\ 

我正在使用Docker,但我正在迁移到k8。

使用docker,我可以通过以下方式访问这些标签:

docker inspect --format "{{ index .Config.Labels \"$label\"}}" $container

如何使用Kubernetes访问这些标签?

我知道要在yaml文件的.Metadata.labels中添加这些标签,但是我不太喜欢,因为 -它将那些信息链接到部署而不是容器本身
-可以随时修改
...

kubectl describe pods

谢谢

2 个答案:

答案 0 :(得分:1)

Kubernetes不会公开该数据。如果是这样,它将成为PodStatus API对象(及其嵌入的ContainerStatus)的一部分,该对象是Pod数据的一部分,{{1} }。

您可能会考虑将某些数据编码在Docker image标签中;例如,如果CI系统正在构建带标记的提交,则使用源控制标签名称作为图像标签,否则使用提交哈希或序列号。另一个典型的途径是使用诸如Helm之类的部署管理器作为有关部署的主要事实来源,如果这样做,从CD系统到Helm到Kubernetes的路径可能会传递标签或注释。您通常还可以设置软件以在构建时知道其自身的构建日期和源代码控制提交ID,然后通过仅提供信息的API(例如HTTP kubectl get pod deployment-name-12345-abcde -o yaml调用等)公开该信息。

答案 1 :(得分:0)

我将添加另一个选项。

我建议阅读有关K8S的Recommended Labels

Key                           Description                     
app.kubernetes.io/name        The name of the application     
app.kubernetes.io/instance    A unique name identifying the instance of an application  
app.kubernetes.io/version     The current version of the application (e.g., a semantic version, revision hash, etc.)
app.kubernetes.io/component   The component within the architecture 
app.kubernetes.io/part-of     The name of a higher level application this one is part of
app.kubernetes.io/managed-by  The tool being used to manage the operation of an application

因此,您可以使用标签来描述广告连播:

apiVersion: apps/v1
kind: Pod # Or via Deployment
metadata:
  labels:
    app.kubernetes.io/name: wordpress
    app.kubernetes.io/instance: wordpress-abcxzy
    app.kubernetes.io/version: "4.9.4"
    app.kubernetes.io/managed-by: helm
    app.kubernetes.io/component: server
    app.kubernetes.io/part-of: wordpress

并使用downward api(其工作方式类似于编程语言中的反射)。

有两种方法可以将Pod和Container字段公开给正在运行的Container:

1)环境变量。
2)卷文件。

以下是使用卷文件的示例:

apiVersion: v1
kind: Pod
metadata:
  name: kubernetes-downwardapi-volume-example
  labels:
    version: 4.5.6
    component: database
    part-of: etl-engine
  annotations:
    build: two
    builder: john-doe
spec:
  containers:
    - name: client-container
      image: k8s.gcr.io/busybox
      command: ["sh", "-c"]
      args:  # < ------ We're using the mounted volumes inside the container
      - while true; do
          if [[ -e /etc/podinfo/labels ]]; then
            echo -en '\n\n'; cat /etc/podinfo/labels; fi;
          if [[ -e /etc/podinfo/annotations ]]; then
            echo -en '\n\n'; cat /etc/podinfo/annotations; fi;
          sleep 5;
        done;
      volumeMounts:
        - name: podinfo
          mountPath: /etc/podinfo
  volumes:   # < -------- We're mounting in our example the pod's labels and annotations
    - name: podinfo
      downwardAPI:
        items:
          - path: "labels"
            fieldRef:
              fieldPath: metadata.labels
          - path: "annotations"
            fieldRef:
              fieldPath: metadata.annotations

请注意,在该示例中,我们访问了传递并安装到/etc/podinfo路径的标签和注释。

除了标签和注释之外,向下的API还提供了多个其他选项,例如:

  • 吊舱的IP地址。
  • 广告连播的服务帐户名称。
  • 节点的名称和IP。
  • 容器的CPU限制,CPU请求,内存限制,内存请求。

here中查看完整列表。


(*)讨论向下API的nice blog


(**)您可以使用

查看所有广告连播标签
$ kubectl get pods --show-labels
NAME                       ...         LABELS
my-app-xxx-aaa                         pod-template-hash=...,run=my-app
my-app-xxx-bbb                         pod-template-hash=...,run=my-app
my-app-xxx-ccc                         pod-template-hash=...,run=my-app 
fluentd-8ft5r                          app=fluentd,controller-revision-hash=...,pod-template-generation=2
fluentd-fl459                          app=fluentd,controller-revision-hash=...,pod-template-generation=2
kibana-xyz-adty4f                      app=kibana,pod-template-hash=...
recurrent-tasks-executor-xaybyzr-13456 pod-template-hash=...,run=recurrent-tasks-executor
serviceproxy-1356yh6-2mkrw             app=serviceproxy,pod-template-hash=...

或仅使用$ kubectl get pods -L <label_name>查看特定标签。