学习K8SAPI和KubeEdge针对设备的API！！！

1. 在KubeEdge中如何调取设备信息？

1.1 Kubeedge-counter-demo中使用RESTClient进行与K8S的交互

在counter这个demo中，主要通过RESTClient（K8S提供给GO的一个客户端）与K8S进行通信。

在云端demo服务中：
云端服务代码

controller中主要就是编写前端页面请求跳入的逻辑代码。
在代码中引入了rest客户端的包：
在这里插入图片描述
在utils包下的crdclient进行对restClient的配置：
在这里插入图片描述
主要配置了APIPath、Group以及version

config.APIPath = "/apis"
//SchemeGroupVersion = schema.GroupVersion{Group: "devices.kubeedge.io", Version: "v1alpha2"}
config.GroupVersion = &devices.SchemeGroupVersion

根据K8S接口文档的格式大致可知道URL：https//IP:port/apis/devices.kubeedge.io/v1alpha2
然后通过controller来看具体位置：
在这里插入图片描述
这是demo中查询状态的请求K8S的方法，由此可推出具体URL：

https//IP:port/apis/devices.kubeedge.io/v1alpha2/namespaces/default/devices/counter

1.2 如何查到更多的API接口呢？

首先我是在本地虚拟机上的K8S创建了一个管理员用户，获取该用户的TOKEN，使用PostMan携带Token进行请求，从而获取本地K8S所有的Api接口，具体操作见：链接（包含命令行和http请求操作，强烈推荐）

获取到API后就可以寻找刚刚推出来的API：

在这里插入图片描述
在K8S的接口文档中并没有这个分组的，我猜想这个应该是KubeEdge自己生成后用来对接K8S的

2. 在K8S中如何通过http请求对命名空间进行增删改查？

2.1 新增命名空间

创建namespace： /api/v1/namespaces

通过post请求携带JSON或者yaml文件进行新增，具体操作如下图：

通过post请求携带JSON或者yaml文件进行新增

结果如下图：

postMan：

通过get请求方式，请求https://192.168.66.130:6443/api/v1/namespaces（携带token，后续使用postman请求都需要token）

在这里插入图片描述

linux：

通过：kubectl get ns name ；例如kubectl gt ns test001.(这里的name可加可不加)

在这里插入图片描述

2.2 修改命名空间

修改指定的命名空间： /api/v1/namespaces/{name}

使用put/patch携带要修改的内容（JSON或Yaml）:

postman修改labels

在这里插入图片描述

== postman结果如下图：==

在这里插入图片描述

linux结果如图：

可以通过 kubectl get ns test001 -o json 去查看test001的配置文件

在这里插入图片描述

只更新状态
修改指定名称空间的状态：/api/v1/namespaces/{name}/status

暂未测出

2.2 删除命名空间

删除namespace： /api/v1/namespaces/{name}

在这里插入图片描述

postman结果如下：

在这里插入图片描述

linux结果如下：

在这里插入图片描述

3. KubeEdge如何通过http请求对设备进行增删改查？

3.1 查看设备

https://192.168.66.130:6443/apis/devices.kubeedge.io/v1alpha2/namespaces/default/devices/counter
这个api是跟着kubeedge-counter-instance.yaml的配置而改变的

在这里插入图片描述

3.2 更改设备状态

https://192.168.66.130:6443/apis/devices.kubeedge.io/v1alpha2/namespaces/default/devices/counter

3.2.1 通过header为merge-patch+json请求

通过patch请求修改headers后携带json文件：

Content-Type:application/merge-patch+json

在这里插入图片描述

json文件

{"status": {
        "twins": [
            {
                "desired": {
                    "metadata": {
                        "timestamp": "1651",# 时间戳的前四位即可
                        "type": "string"
                    },
                    "value": "ON"
                },
                "propertyName": "status",
                "reported": {
                    "metadata": {
                        "timestamp": "1651",
                        "type": "string"
                    },
                    "value": "1"
                }
            }
        ]
    }
}

在这里插入图片描述

3.2.2 通过header为json-patch+json请求

通过patch请求修改headers后携带json文件：

在这里插入图片描述

Content-Type:application/json-patch+json

json文件

[
    {
        "op": "replace",
        "path": "/status/twins/0/desired/value",
        "value": "ON"
    },
    {
        "op": "replace",
        "path": "/status/twins/0/reported/value",
        "value": "1"
    }
]

在这里插入图片描述

3.3 删除设备

https://192.168.66.130:6443/apis/devices.kubeedge.io/v1alpha2/namespaces/default/devices/counter

使用delete请求删除即可

4. 在K8S中如何通过http请求对账户进行增删改查？

4.1 在RBAC中有关账户、角色、权限的概念

1.什么是RBAC?
RBAC全称Role-Based Access Control，是Kubernetes集群基于角色的访问控制，实现授权决策，允许通过Kubernetes API动态配置策略。

2.什么是Role?
Role是一组权限的集合，例如Role可以包含列出Pod权限及列出Deployment权限，Role用于给某个NameSpace中的资源进行鉴权。

3.什么是ClusterRole?
ClusterRole是一组权限的集合，但与Role不同的是，ClusterRole可以在包括所有NameSpace和集群级别的资源或非资源类型进行鉴权。

4.什么是Subject?
Subject：有三种Subjects，Service Account、User Account、Groups，参照官方文档主要区别是User Account针对人，Service Accounts针对运行在Pods中运行的进程。

5.什么是RoleBinding与ClusterRoleBinding?
RoleBinding与ClusterRoleBindin：将Subject绑定到Role或ClusterRole。其区别在于：RoleBinding将使规则在命名空间内生效，而ClusterRoleBinding将使规则在所有命名空间中生效。

4.2 新增账户

https://192.168.66.130:6443/api/v1/namespaces/kube-system/serviceaccounts

使用post请求携带json文件新增用户：

在这里插入图片描述

postman结果：

在这里插入图片描述

linux结果：

在这里插入图片描述

4.3 修改账户

修改test01所在的命名空间为 ：kube-public

请求：https://192.168.66.130:6443/api/v1/namespaces/kube-system/serviceaccounts/test01

使用put携带修改的内容进行请求：

暂未成功
在这里插入图片描述

4.4 删除账户

主要通过delete请求进行删除

在这里插入图片描述

使用postman进行查询：

提示已经找不到了

在这里插入图片描述

4.5 获取用户Token

获取secrets对应的名称api: https://192.168.66.130:6443/api/v1/namespaces/kube-system/serviceaccounts/test01

先获取到账户的secrets对应的名称：test01-token-gm7jr

在这里插入图片描述

获取加密后的token的api： https://192.168.66.130:6443/api/v1/namespaces/kube-system/secrets/test01-token-gm7jr

在这里插入图片描述

此时Token就是加密后的，需要使用base64进行解密

在这里插入图片描述

linux获取Token：

先通过 kubectl describe sa test01 -n kube-system 命令获取Secret的name：
在这里插入图片描述

通过 kubectl describe secret test01-token-gm7jr -n kube-system 命令获取token：（这样获取出来的token是加密前的）

在这里插入图片描述

4.6 设置账户权限

api： https://192.168.66.130:6443/apis/rbac.authorization.k8s.io/v1/clusterrolebindings

在这里插入图片描述

上方权限对应的json配置文件如下：

{
	"apiVersion": "rbac.authorization.k8s.io/v1",
	"kind": "ClusterRoleBinding",
	"metadata":{
		"name": "admin-user"
	},
	"roleRef":{
		"apiGroup": "rbac.authorization.k8s.io",
 		"kind": "ClusterRole",
  		"name": "cluster-admin"
	},
	"subjects":[
		{
		"kind": "ServiceAccount",
	  	"name": "admin-user",
	  	"namespace": "kube-system"
		}
	]
}

4.6.1 新增test01账户ClusterRole权限

使用post请求： https://192.168.66.130:6443/apis/rbac.authorization.k8s.io/v1/clusterrolebindings

body带参数如下：

{
	"apiVersion": "rbac.authorization.k8s.io/v1",
	"kind": "ClusterRoleBinding",
	"metadata":{
		"name": "test01-role"
	},
	"roleRef":{
		"apiGroup": "rbac.authorization.k8s.io",
 		"kind": "ClusterRole",
  		"name": "cluster-admin"
	},
    "subjects":[
		{
		"kind": "ServiceAccount",
	  	"name": "test01",
	  	"namespace": "kube-system"
		}
	]
}

在这里插入图片描述

4.7 设置角色管理权限

4.7.1 查询集群式Role：clusterRole

api: https://192.168.66.130:6443/apis/rbac.authorization.k8s.io/v1/clusterroles

在这里插入图片描述
上图这个权限就是test01账户所具有的权限

4.7.2 新建一个普通角色：Role

api: https://192.168.66.130:6443/apis/rbac.authorization.k8s.io/v1beta1/namespaces/default/roles

使用post携带以下参数进行请求


{
"apiVersion": "rbac.authorization.k8s.io/v1beta1",
"kind": "Role",
"metadata":{
  	"name": "kubeedge-counter",
  	"namespace": "default"  # "namespace" 被忽略，因为 ClusterRoles 不受名字空间限制
  	}
"rules":[
	{
	"apiGroups": ["devices.kubeedge.io"]  # "devices.kubeedge.io" 标明 core API 组
  	"resources": ["devices"]  # resources 的值都是资源类型的复数形式,比如资源类型pod,就要写pods,rolebinding 就要写rolebindings
  	"verbs": ["get", "patch"]
  	}
  ]
}

请求结果如下图：
在这里插入图片描述

5. 在K8S中如何通过http请求对任务进行增删改查？

5.1 查询任务

https://192.168.66.130:6443/apis/batch/v1/namespaces/default/jobs

使用get请求进行任务查询

查询结果如下:

在这里插入图片描述

5.2 新增任务

https://192.168.66.130:6443/apis/batch/v1/namespaces/default/jobs

使用post携带json新增

使边端输出 hello后，过30s输出job

job配置项yaml字段详解：

apiVersion: batch/v1 	# 版本号
kind: Job 			# 类型       
metadata: 			# 元数据
  name: 			# job名称 
  namespace: 		# 所属命名空间 
  labels: 		#标签
    controller: job
spec: 			# 详情描述
  completions: 1 		# 指定job需要成功运行Pods的次数。默认值: 1
  parallelism: 1 		# 指定job在任一时刻应该并发运行Pods的数量。默认值: 1
  activeDeadlineSeconds: 30 		# 指定job可运行的时间期限，超过时间还未结束，系统将会尝试进行终止。
  backoffLimit: 6 			# 指定job失败后进行重试的次数。默认是6
  manualSelector: true 		# 是否可以使用selector选择器选择pod，默认是false
  selector: 			# 选择器，通过它指定该控制器管理哪些pod
    matchLabels:      	# Labels匹配规则
      app: counter-pod
    matchExpressions: 	# Expressions匹配规则
      - {key: app, operator: In, values: [counter-pod]}
  template: 		# 模板，当副本数量不足时，会根据下面的模板创建pod副本
    metadata:
      labels:
        app: counter-pod
    spec:
      restartPolicy: Never 		# 重启策略只能设置为Never或者OnFailure
      containers:
      - name: counter
        image: busybox:1.30
        command: ["bin/sh","-c","for i in 9 8 7 6 5 4 3 2 1; do echo $i;sleep 2;done"]

# 关于重启策略设置的说明：
    如果指定为OnFailure，则job会在pod出现故障时重启容器，而不是创建pod，对应的failed次数不变
    如果指定为Never，则job会在pod出现故障时创建新的pod，并且故障pod不会消失，也不会重启，对应的failed次数加1
    如果指定为Always的话，就意味着一直重启，意味着job任务会重复去执行了，就不能达到一次性目的，所以不能设置为Always

json例子：

{
    "apiVersion":"batch/v1",
    "kind":"Job",
    "metadata":{
        "name":"busbox-job-test"
    },
    "spec":{
        "template":{
            "metadata":{
                "name":"busbox-job-test"
            },
            "spec":{
                "restartPolicy":"Never",
                "containers":[
                	{
                    "name":"busybox-job-container",
                    "image":"busybox",
                    "command": [
                            "sh",
                            "-c"
                        ],
                    "args": [
                            "echo \"hello\";sleep 30; echo \"job\""
                        ]
                	}
                ]
            }
        }
    }
}

postman请求结果如下：

在这里插入图片描述

边端通过 docker logs -f <容器编号> 查看输出内容（如下图）

在这里插入图片描述

5.3 删除任务

https://192.168.66.130:6443/apis/batch/v1/namespaces/default/jobs/busbox-job-test

使用delete方式请求即可

在这里插入图片描述

再次用get方式查询，结果如下：

在这里插入图片描述

6.在KubeEdge中如何管理边缘节点？

6.1查看边缘节点信息

api: https://192.168.66.130:6443/api/v1/nodes/edge1 edge1表示边缘节点的名称

通过get请求查询节点信息

在这里插入图片描述

容器情况、可分配情况、节点状态如下图：

在这里插入图片描述

边缘节点ip、名称和端口号如下图：

在这里插入图片描述

边缘节点设备信息如下图：

在这里插入图片描述

6.2 删除节点

删除之前不用的名为 edge 节点

api: https://192.168.66.130:6443/api/v1/nodes/edge

使用delete请求

在这里插入图片描述
通过linux查询看一下：

没删除之前：

在这里插入图片描述

删除之后：

在这里插入图片描述
删掉了

# kubernetes # edge # 容器
Logo
华为云开发者联盟

为开发者提供学习成长、分享交流、生态实践、资源工具等服务，帮助开发者快速成长。

更多推荐

cover

华为云Stack8.3面向香港正式发布，六大亮点激发云上跃迁

avatar 华为云开发者联盟
cover

GaussDB SQL查询语句执行过程解析

avatar 华为云开发者联盟
cover

6个实例带你解读TinyVue 组件库跨框架技术

avatar 华为云开发者联盟