kubernetes基础知识之downwardAPI 扩展

kubernetes downwardAPI的特性：

①：volume挂载模式会保持热更新特性。

②： 可以传递一个容器的资源字段到另外一个容器中，前提条件是处于同一个pod中。

可以把一个pod的信息放到另外一个pod中，可以基于官方的apiserver接口去做扩展，获取所谓的元数据信息。

downward api提供了一种简单的方式，将pod和容器的元数据传递给在它们内部运行的进程。但是这种方式其实仅仅可以暴露一个pod自身的元数据传递给在它们内部运行的进程。但是这种方式其实仅仅可以暴露一个pod自身的元数据，而且只可以暴露部分元数据。

存在一个api服务器，里面有很多api对象。那么pod中的容器内部进程直接访问api服务器的数据，也是可以做到的。pod中容器内部的进程相当于是apiserver的客户端，从apiserver服务器中去获取数据，而不是基于pod内部或者是官方的机制去实现。

基于apiServer去访问kubernetes集群：

编写一个rbac的yaml文件，创建出rbac的权限，去做授权操作。接着创建出一个sa的用户账户，然后使用带curl命令的镜像去创建一个pod，这个pod是基于访问方式而来的。镜像需要封装curl命令，启动以后休眠9999秒钟。

①：创建rbac的权限：

vim rbac.yaml:

apiVersion: rbac.authorization.k8s.io/v1

kind: ClusterRoleBinding

metadata:

name: test-api-cluster-admin-binding

subjects:

-kind: ServiceAccount

name: test-api

namespace: default

roleRef:

kind: ClusterRole

name: cluster-admin

apiGroup: rbac.authorization.k8s.io

②：创建一个sa用户test-api:

kubectl create sa test-api

③：创建一个pod:

vim pod.yaml:

apiVersion: v1

kind: Pod

metadata:

name: curl

spec:

serviceAccountName: test-api

containers:

- name: main

image: alpine/curl

Command: ["sleep","9999"]

k8s中，每个请求通过kubernetes api与集群资源交互时，都必须通过集群资源对象入口kube-apiserver。每个请求都必须通过合规检查，包括：Authentication身份认证、Authorization授权和Admission Control准入控制。

RBAC是（Role-Based Access Control）基于角色的访问控制，主要由Role角色、ClusterRole集群角色、RoleBinding角色绑定和ClusterRoleBinding集群角色绑定等资源实现。它把权限授予角色之上，然后将权限绑定到Role中，接着用户和Role角色绑定，这样用户就拥有了和role一样的权限。

构成一个Rule规则需要声明三个部分：

①：资源所属的API组。

②：资源

③：动作

查看证书：

openssl x509 -noout -text -in ca.crt

查看身份验证的配置：

kubectl config view

角色分成：Role和ClusterRole，Role用于命名空间内的资源管理，ClusterRole用于管理kubernetes集群级的资源。

绑定分成：RoleBinding和ClusterRoleBinding。

绑定就是将角色与主体（用户、组、服务账户）做关联。

比如开发团队通过RoleBinding获得测试命名空间的权限，运维团队通过ClusterRoleBinding管理整个集群。

进入容器：

kunectl exec -it $pod_name -n $namespace_name -- /bin/bash

设置变量：

TOKEN=$（cat /var/run/secrets/kubernetes.io/serviceaccount/token）

CAPATH="/var/run/secrets/kubernetes.io/serviceaccount/cat.crt"

NS=$(cat /var/run/secrets/kubernetes.io/serviceaccoucatnamespace)

执行:

curl -H "Authorization: Bearer $TOKEN" --cacert $CAPATH https://kunernetes/api/v1/namespaces/$NS/pods

通过去 curl的方式，发起了一个API接口的访问，可以通过API接口访问到pod的相关信息。

kubernetes是kubectl get svc -n $namespace_name得到的，默认是default的命名空间。如果是同名的命名空间下，不需要区写服务名，比如
kubernetes.default.svc.cluster.local，我们只需要写当前的service名字，比如：kubernetes。但是有一个前提，需要访问的pod必须与这个service在同一个命名空间下，才能这样去简化书写，相当于一个缩写值。

kubernetes服务名格式遵循：

服务名.命名空间.svc.cluster.local的域名结构。在默认命名空间default中创建的服务kubernetes，DNS域名格式是：

kubernetes.default.svc.cluster.local

举例执行：

curl -H "Authorization: Bearer $TOKEN" --cacert $CAPATH https://kunernetes/api/v1/namespaces/kube-system/pods

可以获取到pod的信息。

这种方式更灵活，查出来的元信息更多，安全性也需要进一步考量。

这个举例中，授予了集群的最大管理员权限，在真实的生产环境中，需要进一步去缩小它的权限范围。

使用downward API的方式，是另外一种获取当前pod相关属性的方式。

https://kubernetes/api/v1定义了接口组的版本。

可以安装UI界面去查询接口信息：

1.kubectl proxy --port=8080

2.curl localhost:8080/openapi/v2 > k8s-swagger.json

3.docker run --rm -d -p 80:8080 -e SWAGGER_JSON=/k8s-swagger.json -v $pwd/k8s-swagger.json:/k8s-swagger.json swaggerapi/swagger-ui

4.通过浏览器登录：

http://ip地址

swagger-ui是一个图形化的工具，它可以把json文件去理解，翻译成一个可视化的平台，它是可以基于容器化部署的，可以使用docker run命令去实现。

可以通过浏览器进入swagger，在这个界面中可以看到不同的接口，还有对应的案例。我们可以学习这些接口，去获取我们想要的不同功能，这就是官方准备的开发文档。可以基于这些接口，去完成一些自动化的事情。

kubernetes是一个平台，我们可以在这个平台上进行自己自动化业务流程的编辑。

总结：①：通过官方的方式，去获取pod自身的元数据，以此去反馈到我们的业务运行。

②：也可以通过扩展的方式，基于apiserver的接口去获取更多的元数据。

鼓励的话语：所有的隐忍，都是为了未来的腾飞！