Kubernetes学习笔记（七）：访问Pod元数据与Kubernetes API

Downward API

我们已经了解到，使用ConfigMap和Secret向应用传递配置数据，这对于运行前预设的数据是可行的。但是对于那些不能预先知道的，就需要使用Downward API。

Downward API允许我们通过环境变量或者卷的方式向应用传递元数据。可传递的数据包括：Pod的IP、名称、标签、注解、所在命令空间、运行的节点名称、运行所属的ServiceAccountName，每个容器请求的CPU和内存使用量以及限制。

通过环境变量暴露元数据

env.valueFrom下引用Pod的字段使用fieldRef，引用容器的cpu和内存使用resourceFieldRef。
对于暴露资源的请求和使用显示的环境变量，我们通常会设置一个基数单位。实际的资源请求值和使用限制值除以这个基数单位，所得结果通过环境变量暴露出去。

# downward-env.yaml
apiVersion: v1
kind: Pod
metadata:
  name: downward-env
spec:
  containers:
    - name: alpine
      image: alpine
      command: ["sleep","999999"]
      resources:
        requests:
          cpu: 15m
          memory: 100Ki
        limits:
          cpu: 500m
          memory: 100Mi
      env:
      - name: POD_NAME
        valueFrom:
          fieldRef:
            fieldPath: metadata.name
      - name: POD_NAMESPACE
        valueFrom:
          fieldRef:
            fieldPath: metadata.namespace
      - name: POD_IP
        valueFrom:
          fieldRef:
            fieldPath: status.podIP
      - name: NODE_NAME
        valueFrom:
          fieldRef:
            fieldPath: spec.nodeName
      - name: SERVICE_ACCOUNT
        valueFrom:
          fieldRef:
            fieldPath: spec.serviceAccountName
      - name: CONTAINER_CPU_REQ_MILLICORES
        valueFrom:
          resourceFieldRef:
            resource: requests.cpu
            divisor: 1m
      - name: CONTAINER_MEMORY_LIMIT_KIBIBYTES
        valueFrom:
          resourceFieldRef:
            resource: limits.memory
            divisor: 1Ki

查看一下环境变量

-> [root@kube0.vm] [~] k create -f downward-env.yaml
pod/downward-env created

-> [root@kube0.vm] [~] k exec downward-env env
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
HOSTNAME=downward-env
POD_NAME=downward-env
POD_NAMESPACE=default
POD_IP=10.244.1.24
NODE_NAME=kube1.vm
SERVICE_ACCOUNT=default
CONTAINER_CPU_REQ_MILLICORES=15
CONTAINER_MEMORY_LIMIT_KIBIBYTES=102400

通过Downward卷传递元数据

使用downward卷的方式传递元数据，当Pod的标签和注解修改后，Kubernetes会更新存有相关信息的文件。而环境变量方式下，新值无法暴露。

该描述文件定义了一个downward类型的卷，挂载到容器的/tmp/downward。卷中包含的内容是用downwardAPI.items定义的。

# downward-volume.yaml
apiVersion: v1
kind: Pod
metadata:
  name: downward-volume
  labels:
    foo: bar
  annotations:
    key1: value1
    key2: |
      multi
      line
      value
spec:
  containers:
    - name: alpine
      image: alpine
      command: ["sleep","999999"]
      resources:
        requests:
          cpu: 15m
          memory: 100Ki
        limits:
          cpu: 500m
          memory: 100Mi
      volumeMounts:
      - name: downward
        mountPath: /tmp/downward
  volumes:
  - name: downward
    downwardAPI:
      items:
      - path: "podName"
        fieldRef:
            fieldPath: metadata.name
      - path: "podNamespace"
        fieldRef:
            fieldPath: metadata.namespace
      - path: "labels"
        fieldRef:
            fieldPath: metadata.labels
      - path: "annotations"
        fieldRef:
            fieldPath: metadata.annotations
      - path: "containerCpuReqMillicores"
        resourceFieldRef:
          containerName: alpine
          resource: requests.cpu
          divisor: 1m
      - path: "containerMemoryLimitBytes"
        resourceFieldRef:
          containerName: alpine
          resource: limits.memory
          divisor: 1

创建查看

-> [root@kube0.vm] [~] k create -f downward-volume.yaml
pod/downward-volume created

-> [root@kube0.vm] [~] k exec downward-volume ls /tmp/downward
annotations
containerCpuReqMillicores
containerMemoryLimitBytes
labels
podName
podNamespace

与Kubernetes API服务器交互

DownwardAPI可以获得当前Pod的部分元数据，但是无法获得到其他的Pod的，以及一些集群中的其他资源信息。

Kubernetes REST API

先来查看集群信息，找到API服务器地址。然后 curl -k https://192.168.199.117:6443 ，当然结果也是访问受限的。

-> [root@kube0.vm] [~] k cluster-info
Kubernetes master is running at https://192.168.199.117:6443
KubeDNS is running at https://192.168.199.117:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

所以我们通过 kubectl proxy 访问API服务器。kubectl proxy启动一个代理，接收来自本机的HTTP请求并验证身份，转发到API服务器。

-> [root@kube0.vm] [~] k proxy
Starting to serve on 127.0.0.1:8001

新开一个窗口，访问根路径实时

-> [root@kube0.vm] [~] curl http://localhost:8001/
{
  "paths": [
    "/api",
    "/api/v1",
    "/apis",
    "/apis/",
............

从pod内部与API服务器交互

确定API服务器的地址

-> [root@kube0.vm] [~] k get svc
NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   10.96.0.1    <none>        443/TCP   2d1h

或者从任意Pod查找服务的环境变量

-> [root@kube0.vm] [~] k exec myalpine env|grep KUBERNETES_SERVICE
KUBERNETES_SERVICE_PORT=443
KUBERNETES_SERVICE_PORT_HTTPS=443
KUBERNETES_SERVICE_HOST=10.96.0.1

用一个有curl的镜像启动一个Pod

首先验证服务器身份，定义CURL_CA_BUNDLE环境变量，省去每次都要 curl --cacert 指定证书

export CURL_CA_BUNDLE=/var/run/secrets/kubernetes.io/serviceaccount/ca.crt

其次获得服务器授权：定义TOKEN

export TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)

绕过RBAC，赋予所有服务账户（也可以说所有pod）的集群管理员权限。

-> [root@kube0.vm] [~] k create clusterrolebinding permissive-binding --clusterrole=cluster-admin --group=system:serviceaccounts
clusterrolebinding.rbac.authorization.k8s.io/permissive-binding created

访问API服务器

$ curl -H "Authorization: Bearer $TOKEN" https://kubernetes/
{
  "paths": [
    "/api",
    "/api/v1",
...........

获取当前运行Pod所在的命名空间

export NS=$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace)

列出当前命名空间的Pods

$ curl -H "Authorization: Bearer $TOKEN" https://kubernetes/api/v1/namespaces/$NS/pods
{
  "kind": "PodList",
  "apiVersion": "v1",
  "metadata": {
    "selfLink": "/api/v1/namespaces/default/pods",
    "resourceVersion": "454829"
..........

简化与API服务器的交互

在Pod中，除了主容器外另起一个运行kubectl proxy的容器，这样主容器就可以通过http://127.0.0.1:8001/访问API服务器了。

先构建镜像，准备kubectl-proxy.sh和Dockerfile。

# kubectl-proxy.sh

#!/bin/sh

API_SERVER="https://$KUBERNETES_SERVICE_HOST:$KUBERNETES_SERVICE_PORT"
CA_CRT="/var/run/secrets/kubernetes.io/serviceaccount/ca.crt"
TOKEN="$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)"

/kubectl proxy --server="$API_SERVER" --certificate-authority="$CA_CRT" --token="$TOKEN" --accept-paths='^.*'

myalpine就是一个安装了curl的自制镜像

# Dockerfile
FROM registry.cn-hangzhou.aliyuncs.com/orzi/myalpine
RUN curl -LO https://storage.googleapis.com/kubernetes-release/release/v1.18.0/bin/linux/amd64/kubectl && chmod +x ./kubectl && mv ./kubectl /
COPY kubectl-proxy.sh /kubectl-proxy.sh
ENTRYPOINT ["/kubectl-proxy.sh"]

构建、推送

docker build -t registry.cn-hangzhou.aliyuncs.com/orzi/myalpine:kubeproxy .

docker push registry.cn-hangzhou.aliyuncs.com/orzi/myalpine:kubeproxy

描述文件

# mykubeproxy.yaml
apiVersion: v1
kind: Pod
metadata:
  name: mykubeproxy
spec:
  containers:
    - name: myalpine
      image: registry.cn-hangzhou.aliyuncs.com/orzi/myalpine
      command: ["sleep","999999"]
    - name: mykubeproxy
      image: registry.cn-hangzhou.aliyuncs.com/orzi/myalpine:kubeproxy

创建、查看

-> [root@kube0.vm] [~] k create -f mykubeproxy.yaml
pod/mykubeproxy created

-> [root@kube0.vm] [~] k exec -it mykubeproxy -c myalpine sh

$ curl http://127.0.0.1:8001
{
  "paths": [
    "/api",
    "/api/v1",
    "/apis",
.......

小结

• Downward API允许我们将不能预先知道的Pod元数据通过环境变量或者卷的方式传递给应用。
• Downward API可传递的数据包括：Pod的IP、名称、标签、注解、所在命名空间、运行的节点名称、运行所属的ServiceAccountName，每个容器请求的CPU和内存的使用量和限制。
• env.valueFrom下引用Pod的字段使用fieldRef，引用容器的cpu和内存使用resourceFieldRef。
• 对于暴露资源的请求和使用显示的环境变量，我们通常会设置一个基数单位。实际的资源请求值和使用限制值除以这个基数单位，所得结果通过环境变量暴露出去。
• 使用downward卷的方式传递元数据，当Pod的标签和注解修改后，Kubernetes会更新存有相关信息的文件。而环境变量方式下，新值无法暴露。
• 可以通过运行kubectl proxy后，在节点上访问API服务器。也可以在Pod中另起一个专门运行kubectl proxy的容器，在主容器中访问。