绕过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的容器，这样主容器就可以通过: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 :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的容器，在主容器中访问。