程序员求职经验分享与学习资料整理平台

网站首页 > 文章精选 正文

kubernetes基础知识之downwardAPI 扩展

balukai 2025-07-09 10:58:00 文章精选 3 ℃

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的接口去获取更多的元数据。

鼓励的话语:所有的隐忍,都是为了未来的腾飞!

最近发表
标签列表