如何访问 pod 元数据
**我们在 pod 中运行容器的时候，是否也会有想要获取当前 pod 的环境信息呢？**咱们写的 yaml 清单写的很简单，实际上部署之后， k8s 会给我们补充在 yaml 清单中没有写的字段，那么我们的 pod 环境信息和容器的元数据如何传递到容器中呢？是不是也是通过获取这些 k8s 默认给我填写的字段呢？
有 3 种方式：
- 通过环境变量的方式
- 通过 Downward Api 的方式
- 通过和 ApiServer 交互的方式
通过环境变量的方式
通过环境变量的方式获取 pod 的信息，还是比较简单的，还记得我们之前将卷中的数据转成环境变量传入到容器中的方式吗？
本次我们也是使用类似的方式来传递数据，应该说比之前的还要简单，不过我们本次传递的是环境信息，例如 pod 的 IP，pod 的 名称，命名空间，pod 所属的服务账号，节点的名称，CPU / 内存的请求 / 限制大小等等
来我们任意看一下 pod 的 yaml 清单信息
上述 yaml 清单信息中，每一个字段我们都可以用来传递到容器中作为环境变量，我们可以来尝试写一个
- 写一个 yaml 清单，创建名称为 my-downward 的 pod
- 容器里面的使用 busybox 作为基础镜像，由于容器需要运行在 pod 中，因此我们需要运行一个程序在容器中，例如 sleep 8888888 或者其他的任意一个可以长期运行的程序
apiVersion: v1
kind: Pod
metadata:
name: my-downward
spec:
containers:
- name: my-downward
image: busybox
command: ["sleep","8888888"]
env:
- name: XMT_POD_NAME
valueFrom:
fieldRef:
fieldPath: metadata.name
- name: XMT_NAMESPACE
valueFrom:
fieldRef:
fieldPath: metadata.namespace
- name: XMT_NODENAME
valueFrom:
fieldRef:
fieldPath: spec.nodeName
- name: XMT_SERVICE_ACCOUNT
valueFrom:
fieldRef:
fieldPath: spec.serviceAccountName
- name: XMT_REQUEST_CPU
valueFrom:
resourceFieldRef:
resource: requests.cpu
divisor: 1m
- name: XMT_LIMITS_MEMORY
valueFrom:
resourceFieldRef:
resource: limits.memory
divisor: 1Ki
上述自己配置了多个 XMT_* 的环境变量，来源都是在 pod 中的对应配置，kubectl create 上述 yaml 文件后，可以查看效果如下
环境变量如上所示，当我们容器里面需要使用该环境变量的时候，就可以随取随用了，很方便
可以看到容器中的环境变量和 yaml 清单上的 env 一一对应
通过 Downward Api 卷的方式
当然，我们也可以使用第二种方式，那就是通过 Downward Api 卷的方式，具体的操作方式和上述环境变量的方式类似，但是使用卷的方式，会在指定的路径下生成文件
Downward Api 看上去会不会想起 Restful Api，是不是都是通过访问接口的方式获取数据呢？
并不是这样的， Downward Api 实际上是将 pod 的定义和状态信息，作为容器的环境变量或者文件的方式，来给容器传递数据的，如图
Downward Api 卷的方式可以这么写：
apiVersion: v1
kind: Pod
metadata:
name: my-downward-vv
labels:
xmtconf: dev
spec:
containers:
- name: my-downward-vv
image: busybox
command: ["sleep","8888888"]
volumeMounts:
- name: my-downward-vv
mountPath: /etc/myvv
volumes:
- name: my-downward-vv
downwardAPI:
items:
- path: "xmtPodName"
fieldRef:
fieldPath: metadata.name
- path: "xmtNamespace"
fieldRef:
fieldPath: metadata.namespace
- path: "xmtLabels"
fieldRef:
fieldPath: metadata.labels
看这个 yaml 还是比较简单的，和写挂载的方式类似的，此处使用 downwardAPI 下的 items，来传递每一个数据，数据的来源写法和上述的环境变量类似
我们可以看到，Downward Api 挂载数据，具体的文件里面会以键值对的方式来呈现，也会以文本的形式来呈现
我们来将 pod 的标签修改成 prod，验证容器里面对应的文件是否会对应修改？
kubectl label pod my-downward-vv xmtconf=prod --overwrite
进入容器中查看 /etc/myvv/xmtLabels 文件是否有变化
通过上述效果，可以看出，当使用 Downward Api 卷的时候，对应的环境变量会以文件的形式存在于我们指定的目录下
若我们在程序运行中修改了环境变量对应的值，那么卷中的文件内容也会相应修改
如何与 APiServer 进行交互？
既然可以用第三种方式与 ApiServer 的方式，咋还使用环境变量和 Downward Api 的方式呢？
自然是因为 Downward Api 的方式有所局限，局限就是 Downward Api 的方式只能获取自身 pod 的数据，如果我们想获取其他 pod 的资源信息，这个时候我们就需要和 Api Server 进行交互了
类似于这样：
那么我们来写一个 pod， 让 pod 里面的容器与 ApiServer 进行交互，此处我们需要注意两点：
- 我们要确定 ApiServer 的位置，我们才能有机会正确访问到
- 需要通过 ApiServer 的认证
咱们写一个 pod ，用于在这个 pod 里面使用 curl 访问 ApiServer
自己制作一个简单的带有 curl 的镜像
FROM ubuntu:latest
RUN apt-get update -y
RUN apt install curl -y
ENTRYPOINT ["sleep", "8888888"]
制作该镜像，推送镜像到 dockerhub
docker build -t xiaomotong888/xmtcurl .
docker push xiaomotong888/xmtcurl
写一个简单的 yaml，运行 pod
mycurl.yaml
apiVersion: v1
kind: Pod
metadata:
name: xmt-curl
spec:
containers:
- name: xmt-curl
image: xiaomotong888/xmtcurl
command: ["sleep","8888888"]
pod 运行成功后，咱们进入到 容器里面
kubectl exec -it xmt-curl bash
咱们可以在 k8s 环境中查看一下 kubernetes 服务的 ip ，我们可以这样来访问
在容器中访问 kubernetes
这是因为没有证书，我们需要导入证书和 token ， 这样才能正确的访问到 ApiServer，并且还需要一个重要的操作
创建一个 clusterrolebinding，需要创建了该绑定之后，才能正常的访问到 ApiServer，若没有创建该绑定，那么后面的步骤都做好了，ApiServer 也会报 403 Forbidden
kubectl create clusterrolebinding gitlab-cluster-admin --clusterrole=cluster-admin --group=system:serviceaccounts --namespace=dev
证书的位置还记的吗？
之前我们查看过默认的 k8s 挂载的位置，/var/run/secrets/kubernetes.io/serviceaccount 这里面有 命名空间，证书，token
这个时候，我们访问 k8s ApiServer 的时候，可以加上该证书
curl --cacert /var/run/secrets/kubernetes.io/serviceaccount/ca.crt https://kubernetes
我们可以导入一个环境变量，访问 k8s ApiServer 的时候就不需要收到导入证书了
export CURL_CA_BUNDLE=/var/run/secrets/kubernetes.io/serviceaccount/ca.crt
https://gitee.com/common_dev/mypic20220206/raw/master/image-20220204152125059.png
可以看到效果和刚才不一样了，现在报 403 是因为没有 token ，这个时候，我们在加上 token 即可
TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
这样就可以看到 apiServer 都有哪些 api 了 ， 这些 api 可都是我们在写 yaml 清单时候 apiVersion 的是时候填写的
那么用一个图来结束今天的分享
容器里面的应用通过证书与 ApiServer 完成认证，通过 token 和 namespace 和 ApiServer 完成接口的交互
今天就到这里，学习所得，若有偏差，还请斧正
欢迎点赞，关注，收藏
朋友们，你的支持和鼓励，是我坚持分享，提高质量的动力
好了，本次就到这里
技术是开放的，我们的心态，更应是开放的。拥抱变化，向阳而生，努力向前行。
我是阿兵云原生，欢迎点赞关注收藏，下次见~
更多的可以查看 零声每晚八点直播：https://ke.qq.com/course/417774
