python数据可视化工具测评

2401_85979589

于 2024-07-15 13:11:43 发布

阅读量564

点赞数 26

文章标签： notepad++

本文链接：https://blog.csdn.net/2401_85979589/article/details/140436116

版权

欢迎来到今天的讨论，我们将探讨，python数据可视化工具有哪些 python数据可视化优秀案例，一起探索吧！

大家好，小编来为大家解答以下问题，华为python语言通用编程规范，python云计算有哪些岗位，今天让我们一起来看看吧！

一、KubeEdge 简介

① 什么是 KubeEdge ？

KubeEdge 是一个开源的系统，可将本机容器化应用编排和管理扩展到边缘端设备python语法错误撤回方法,python语法错误怎么解决。它基于 Kubernetes 构建，为网络和应用程序提供核心基础架构支持，并在云端和边缘端部署应用，同步元数据python自动化运维库。KubeEdge 还支持 MQTT 协议，允许开发人员编写客户逻辑，并在边缘端启用设备通信的资源约束。KubeEdge 包含云端和边缘端两部分，使用 KubeEdge，可以很容易地将已有的复杂机器学习、图像识别、事件处理和其他高级应用程序部署到边缘端并进行使用。随着业务逻辑在边缘端上运行，可以在本地保护和处理大量数据。通过在边缘端处理数据，响应速度会显著提高，并且可以更好地保护数据隐私。KubeEdge 是一个由 Cloud Native Computing Foundation (CNCF) 托管的孵化级项目，CNCF 是对 KubeEdge 的孵化公告。

② KubeEdge 的优势

Kubernetes 原生支持：使用 KubeEdge 用户可以在边缘节点上编排应用、管理设备并监控应用程序/设备状态，就如同在云端操作 Kubernetes 集群一样。云边可靠协作：在不稳定的云边网络上，可以保证消息传递的可靠性，不会丢失。边缘自治：当云边之间的网络不稳定或者边缘端离线或重启时，确保边缘节点可以自主运行，同时确保边缘端的应用正常运行。边缘设备管理：通过 Kubernetes 的原生 API，并由 CRD 来管理边缘设备。极致轻量的边缘代理：在资源有限的边缘端上运行的非常轻量级的边缘代理（EdgeCore）。

③ KubeEdge 的工作原理

KubeEdge 由云端和边缘端部分构成：

云上部分： CloudHub 是一个 Web Socket 服务端，负责监听云端的变化，缓存并发送消息到 EdgeHub； EdgeController 是一个扩展的 Kubernetes 控制器，管理边缘节点和 Pods 的元数据确保数据能够传递到指定的边缘节点； DeviceController 是一个扩展的 Kubernetes 控制器，管理边缘设备，确保设备信息、设备状态的云边同步。边缘部分： EdgeHub 是一个 Web Socket 客户端，负责与边缘计算的云服务（例如 KubeEdge 架构图中的 Edge Controller）交互，包括同步云端资源更新、报告边缘主机和设备状态变化到云端等功能； Edged 是运行在边缘节点的代理，用于管理容器化的应用程序； EventBus 是一个与 MQTT 服务器 (mosquitto) 交互的 MQTT 客户端，为其他组件提供订阅和发布功能； ServiceBus 是一个运行在边缘的 HTTP 客户端，接受来自云上服务的请求，与运行在边缘端的 HTTP 服务器交互，提供了云上服务通过 HTTP 协议访问边缘端 HTTP 服务器的能力； DeviceTwin 负责存储设备状态并将设备状态同步到云，它还为应用程序提供查询接口； MetaManager 是消息处理器，位于 Edged 和 Edgehub 之间，它负责向轻量级数据库 (SQLite) 存储/检索元数据。

④ 升级 KubeEdge

在每个边缘节点上备份 edgecore 数据库：

$ mkdir -p /tmp/kubeedge_backup
$ cp  /tmp/kubeedge_backup/

您可以保留旧的配置，根据需要保存一些自定义更改。升级后，某些选项可能会被删除，而某些选项可能会被添加，请不要直接使用旧的配置。如果从 1.3 升级到 1.4，请注意会将设备 API 从 v1alpha1 升级到 v1alpha2，需要安装 Device v1alpha2 和 DeviceModel v1alpha2，并将它们现有的自定义资源从 v1alpha1 手动转换为 v1alpha2，如果需要回滚，建议将 v1alpha1 CRD 和自定义资源保留在集群中或导出到某个位置。确保所有 Edgecore 进程均已停止后，一个一个停止 edgecore 的进程，然后停止 cloudcore。停止的方式取决于部署方式：使用二进制 or “keadm” 方式: 使用 kill；使用 “systemd”方式: 使用 systemctl。清理：

$ rm -rf /var/lib/kubeedge /etc/kubeedge

在每个边缘节点还原数据库：

$ mkdir -p /var/lib/kubeedge
$ mv  /var/lib/kubeedge/

二、KubeEdge 的部署

① 使用 Keadm 进行部署

Keadm 用于安装 KubeEdge 的云端和边缘端组件，它不负责 K8s 的安装和运行。可以参考 Kubernetes-compatibility 了解 Kubernetes 兼容性来确定安装哪个版本的 Kubernetes。Keadm 目前支持 Ubuntu 和 CentOS OS，RaspberryPi 的支持正在进行中，并且需要超级用户权限（或 root 权限）才能运行。

（A）设置云端（KubeEdge 主节点）

keadm init： keadm init 将安装 cloudcore，生成证书并安装 CRD（默认情况下边缘节点需要访问 cloudcore 中 10000、10002 端口），它还提供了一个命令行参数，通过它可以设置特定的版本。必须正确配置 kubeconfig 或 master 中的至少一个，以便可以将其用于验证 k8s 集群的版本和其他信息。请确保边缘节点可以使用云节点的本地 IP 连接云节点，或者需要使用 --advertise-address 标记指定云节点的公共 IP 。 –advertise-address（仅从 1.3 版本开始可用）是云端公开的地址（将添加到 CloudCore 证书的 SAN 中），默认值为本地 IP。 keadm init 将会使用二进制方式部署 cloudcore 为一个系统服务，如果想实现容器化部署，可以参考 keadm beta init。 keadm init 如下所示：

# keadm init --advertise-address="THE-EXPOSED-IP"(only work since 1.3 release)

输出：

Kubernetes version verification passed, KubeEdge installation will start...
...
KubeEdge cloudcore is running, For logs visit:

keadm beta init：现在可以使用 keadm beta init 进行云端组件安装：

# keadm beta init --advertise-address="THE-EXPOSED-IP" --set cloudcore-tag=v1.9.0

还可使用 --external-helm-root 安装外部的 helm chart 组件，如 edgemesh：

# keadm beta init --set server.advertiseAddress="THE-EXPOSED-IP" --set server.nodeName=allinone   --force  --profile=edgemesh

keadm beta manifest generate 可以帮助我们快速渲染生成期望的 manifests 文件，并输出在终端显示：

# keadm beta manifest generate --advertise-address="THE-EXPOSED-IP"  >

(B) 设置边缘端（KubeEdge 工作节点）

从云端获取令牌:在云端运行 keadm gettoken 将返回token令牌，该令牌将在加入边缘节点时使用：

# keadm gettoken
27a37ef16159f7d3be8fae95d588b79b3adaaf92727b72659eb89758c66ffda2.eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE1OTAyMTYwNzd9.JBj8LLYWXwbbvHKffJBpPd5CyxqapRQYDIXtFZErgYE

keadm join 将安装 edgecore 和 mqtt。它还提供了一个命令行参数，通过它可以设置特定的版本：

# keadm join --cloudcore-ipport=192.168.20.50:10000 --token=27a37ef16159f7d3be8fae95d588b79b3adaaf92727b72659eb89758c66ffda2.eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE1OTAyMTYwNzd9.JBj8LLYWXwbbvHKffJBpPd5CyxqapRQYDIXtFZErgYE

可以使用 keadm beta join 通过镜像下载所需资源，进行节点接：

# keadm beta join --cloudcore-ipport=192.168.20.50:10000 --token=27a37ef16159f7d3be8fae95d588b79b3adaaf92727b72659eb89758c66ffda2.eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE1OTAyMTYwNzd9.JBj8LLYWXwbbvHKffJBpPd5CyxqapRQYDIXtFZErgYE

# keadm beta join --cloudcore-ipport=192.168.20.50:10000 --runtimetype remote --remote-runtime-endpoint  --token=27a37ef16159f7d3be8fae95d588b79b3adaaf92727b72659eb89758c66ffda2.eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE1OTAyMTYwNzd9.JBj8LLYWXwbbvHKffJBpPd5CyxqapRQYDIXtFZErgYE

输出：

Host has mosquit+ already installed and running. Hence skipping the installation steps !!!
...
KubeEdge edgecore is running, For logs visit:

说明： –cloudcore-ipport 是必填参数；如果您需要的话，加上 --token 会自动为边缘节点生成证书；需要保证云和边缘端使用的 KubeEdge 版本相同；加上 --with-mqtt 会自动为边缘节点以容器运行的方式部署 mosquitto 服务。

（C）启用 kubectl logs 功能

kubectl logs 必须在使用 metrics-server 之前部署，通过以下操作激活功能：确保可以找到 Kubernetes 的和文件，如果通过 kubeadm 安装 Kubernetes 集群，这些文件将位于 /etc/kubernetes/pki/ 目录中：

ls /etc/kubernetes/pki/

设置 CLOUDCOREIPS 环境，环境变量设置为指定的 cloudcore 的 IP 地址，如果具有高可用的集群，则可以指定 VIP（即弹性 IP/虚拟 IP）：

export CLOUDCOREIPS="192.168.0.139"

使用以下命令检查环境变量：

echo $CLOUDCOREIPS

在云端节点上为 CloudStream 生成证书，但是生成的文件不在 /etc/kubeedge/ 中，需要从GitHub的存储库中拷贝一份。将用户更改为 root：

```shell
sudo su

从原始克隆的存储库中拷贝证书：shell cp $ /etc/kubeedge/ 将目录更改为 kubeedge 目录：shell cd /etc/kubeedge/ 从生成证书 bash stream。需要在主机上设置 iptables，此命令应该在每个 apiserver 部署的节点上执行，在这种情况下，须在 master 节点上执行，并由 root 用户执行此命令，在运行每个 apiserver 的主机上运行以下命令：

bash
iptables -t nat -A OUTPUT -p tcp --dport 10350 -j DNAT --to $CLOUDCOREIPS:10003

如果不确定是否设置了 iptables，并且希望清除所有这些表（如果错误地设置 iptables，它将阻止使用 kubectl logs 功能），可以使用以下命令清理 iptables 规则：

shell iptables -F && iptables -t nat -F && iptables -t mangle -F && iptables -X

和上 cloudcore 和 edgecore 都要修改，将 cloudStream 和 edgeStream 设置为 enable: true，将服务器 IP 更改为 cloudcore IP（与 $ CLOUDCOREIPS 相同），打开 YAML 文件：

shell
sudo nano

在以下文件中修改( enable: true )内容：

yaml cloudStream: enable: true streamPort: 10003 tlsStreamCAFile:  tlsStreamCertFile:  tlsStreamPrivateKeyFile:  tlsTunnelCAFile:  tlsTunnelCertFile:  tlsTunnelPrivateKeyFile:  tunnelPort: 10004

在 edgecore 中打开 YAML 文件：

shell sudo nano

修改以下部分中的文件 (enable: true), (server: 192.168.0.193:10004):

yaml
edgeStream:
  enable: true
  handshakeTimeout: 30
  readDeadline: 15
  server: 192.168.0.139:10004
  tlsTunnelCAFile: 
  tlsTunnelCertFile: 
  tlsTunnelPrivateKeyFile: 
  writeDeadline: 15

重新启动所有 cloudcore 和 edgecore：

sudo su

pkill cloudcore
nohup cloudcore >  2>&1 &

kubectl -n kubeedge rollout restart deployment cloudcore

systemctl restart edgecore.service

可以考虑避免 kube-proxy 部署在 edgenode 上，有两种方法：

// 1.通过调用 `kubectl edit  -n kube-system kube-proxy` 添加以下设置：
yaml
affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchExpressions:
              - key: 
                operator: DoesNotExist
                
// 2.如果您仍然要运行 `kube-proxy`，请通过在以下位置添加 `edgecore.service` 中的 env 变量来要求 **edgecore** 不进行检查edgecore.service：
shell
    sudo vi /etc/kubeedge/edgecore.service
    
// 将以下行添加到 **edgecore.service** 文件：
shell
    Environment="CHECK_EDGECORE_ENVIRONMENT=false"
    
// 最终文件应如下所示：
Deion=edgecore.service

    [Service]
    Type=simple
    ExecStart=/root/cmd/ke/edgecore --logtostderr=false 
    Environment="CHECK_EDGECORE_ENVIRONMENT=false"

    [Install]
    WantedBy=multi-user.target

(D) 在云端支持 Metrics-server

实现该功能点的是重复使用 cloudstream 和 edgestream 模块,因此还需要执行启用 kubectl logs 功能的所有步骤。由于边缘节点和云节点的 kubelet 端口不同，故当前版本的 metrics-server（0.3.x）不支持自动端口识别（这是 0.4.0 功能），因此现在需要手动编译从 master 分支拉取的镜像。Git clone 最新的 metrics server 代码仓:

bash
git clone

转到 metrics server 目录：

bash
cd metrics-server

制作 docker 容器：

bash
make container

检查您是否有此 docker 镜像：

bash
docker images

确保使用镜像 ID 来对镜像标签进行变更，以使其与 yaml 文件中的镜像名称一致：

bash
docker tag a24f71249d69 metrics-server-kubeedge:latest

需要通过以下命令使主节点可调度：

shell
kubectl taint nodes --all

需要将这些设置写入部署 yaml（）文件中，如下所示：

yaml
      volumes:
      # mount in tmp so we can safely use from-scratch images and/or read-only containers
      - name: tmp-dir
        emptyDir: {}
      hostNetwork: true                          #Add this line to enable hostnetwork mode
      containers:
      - name: metrics-server
        image: metrics-server-kubeedge:latest    #Make sure that the REPOSITORY and TAG are correct
        # Modified args to include --kubelet-insecure-tls for Docker Desktop (don't use this flag with a real k8s cluster!!)
        imagePullPolicy: Never                   #Make sure that the deployment uses the image you built up
        args:
          - --cert-dir=/tmp
          - --secure-port=4443
          - --v=2
          - --kubelet-insecure-tls
          - --kubelet-preferred-address-types=InternalDNS,InternalIP,ExternalIP,Hostname
          - --kubelet-use-node-status-port       #Enable the feature of --kubelet-use-node-status-port for Metrics-server
        ports:
        - name: main-port
          containerPort: 4443
          protocol: TCP

(E) 重置 KubeEdge master 节点和工作节点

keadm reset 将停止 cloudcore 并从 Kubernetes master 中删除与KubeEdge相关的资源，如 kubeedge 命名空间，它不会卸载/删除任何先决条件。它为用户提供了一个标志，以指定 kubeconfig 路径，默认路径为：

# keadm reset --kube-config=$

② 使用二进制部署

（A）设置云端（KubeEdge 主节点）

创建 CRD：

kubectl apply -f 
kubectl apply -f 
kubectl apply -f 
kubectl apply -f 
kubectl apply -f 
kubectl apply -f

准备配置文件：

# cloudcore --minconfig >

运行：

# cloudcore --config

(B) 设置边缘端（KubeEdge 工作节点）

生成配置文件：

# edgecore --minconfig >

在云端获取 token 值：

# kubectl get secret -nkubeedge tokensecret -o=jsonpath='{.data.tokendata}' | base64 -d

更新 edgecore 配置文件中的 token 值：

# sed -i -e "s|token: .*|token: ${token}|g"

如果要在同一主机上运行 cloudcore 和 edgecore ，请首先运行以下命令：

# export CHECK_EDGECORE_ENVIRONMENT="false"

运行 edgecore:

# edgecore --config

运行 edgecore -h 以获取帮助信息，并在需要时添加选项。

© 局限性

需要超级用户权限（或 root 权限）才能运行。使用二进制部署 KubeEdge 进行测试，切勿在生产环境中使用这种方式。

三、配置 CloudCore 和 EdgeCore

① 配置云端（KubeEdge Master 节点）

（A）修改配置文件

Cloudcore 要求更改配置文件，创建并设置 cloudcore 配置文件，创建 /etc/kubeedge/config 文件夹：

# the default configuration file path is ''
# also you can specify it anywhere with '--config'
mkdir -p /etc/kubeedge/config/

使用 ~/kubeedge/cloudcore --minconfig 命令获取最小配置模板：

~/kubeedge/cloudcore --minconfig >

或使用 ~/kubeedge/cloudcore --defaultconfig 命令获取完整配置模板：

~/kubeedge/cloudcore --defaultconfig >

编辑配置文件：

vim

(B) 修改

无论是 kubeAPIConfig.kubeConfig 或 kubeAPIConfig.master，都可能 kubeconfig 文件的路径，同时它也可能是：



// 或者

/home/<your_username>/.kube/config

在安装 kubernetes 的地方执行以下步骤：

要开始使用集群，您需要以普通用户身份运行以下命令

mkdir -p $
sudo cp -i  $
sudo chown $(id -u):$(id -g) $

默认情况下，cloudcore 使用 https 连接到 Kubernetes apiserver。如果 master 和 kubeConfig 都进行了配置，master 将覆盖 kubeconfig 中的对应值。在 advertiseAddress 中配置所有暴露给边缘节点（如动态 IP）的 CloudCore 的 IP 地址，这些 IP 地址将添加到 CloudCore 证书中的 SAN 中。

modules:
  cloudHub:
    advertiseAddress:
    - 10.1.11.85

© 在云端（KubeEdge master 节点）添加边缘节点（KubeEdge 工作节点）

如果 edgecore 的配置中的 modules.edged.registerNode 设置为 true，Edge 节点则会自动注册：

modules:
  edged:
    registerNode: true

复制 $ 到您的工作目录并更改为边缘节点的名称：

mkdir -p ~/kubeedge/yaml
cp $ ~/kubeedge/yaml

② 配置边缘端（KubeEdge 工作节点）

（A）创建并设置 Edgecore 配置文件

创建 /etc/kubeedge/config 文件夹：

# the default configration file path is ''
# also you can specify it anywhere with '--config'
    mkdir -p /etc/kubeedge/config/

使用 ~/kubeedge/edgecore --minconfig 命令创建最简配置：

~/kubeedge/edgecore --minconfig >

或使用 ~/kubeedge/edgecore --defaultconfig 命令创建完整配置：

~/kubeedge/edgecore --defaultconfig >

编辑配置文件：

vim

(B) 修改

检查 modules.edged.podSandboxImage，请运行以下命令：

shell
getconf LONG_BIT

+ `kubeedge/pause-arm:3.1` for arm arch
+ `kubeedge/pause-arm64:3.1` for arm64 arch
+ `kubeedge/pause:3.1` for x86 arch

KubeEdge v1.3之前的版本：检查 modules.edgehub.tlsCaFile 、modules.edgehub.tlsCertFile 和 modules.edgehub.tlsPrivateKeyFile 的证书文件是否存在。如果这些文件不存在，需要从云端拷贝它们。KubeEdge v1.3之后的版本：仅跳过以上有关证书文件的检查，但是如果手动配置 Edgecore 证书，则必须检查证书的路径是否正确。在 modules.edgehub.websocket.server 和 .server 字段中更新 KubeEdge CloudCore 的 IP 地址和端口，需要设置 cloudcore 的 IP 地址。配置 docker 或 remote 作为所需的 runtime 的容器（对于所有基于 CRI 的runtime（包括容器））。如果未指定此参数，则默认情况下将使用 docker 作为 runtime 的容器：

runtimeType: docker
// 或者
runtimeType: remote

如果运行类型是 remote，请遵循 KubeEdge CRI 配置指南来设置基于 remote/CRI 的运行时的 KubeEdge。在用于申请证书的 modules.edgehub.httpServer 中配置 KubeEdge cloudcore 的 IP 地址和端口，例如：

modules:
  edgeHub:
    httpServer: https://10.1.11.85:10002

配置 token：

kubectl get secret tokensecret -n kubeedge -oyaml

将获得如下内容：

apiVersion: v1
data:
  tokendata: ODEzNTZjY2MwODIzMmIxMTU0Y2ExYmI5MmRlZjY4YWQwMGQ3ZDcwOTIzYmU3YjcyZWZmOTVlMTdiZTk5MzdkNS5leUpoYkdjaU9pSklVekkxTmlJc0luUjVjQ0k2SWtwWFZDSjkuZXlKbGVIQWlPakUxT0RreE5qRTVPRGw5LmpxNENXNk1WNHlUVkpVOWdBUzFqNkRCdE5qeVhQT3gxOHF5RnFfOWQ4WFkK
kind: Secret
metadata:
  creationTimestamp: "2020-05-10T01:53:10Z"
  name: tokensecret
  namespace: kubeedge
  resourceVersion: "19124039"
  selfLink: /api/v1/namespaces/kubeedge/secrets/tokensecret
  uid: 48429ce1-2d5a-4f0e-9ff1-f0f1455a12b4
type: Opaque

通过 base64 解码 tokendata 字段：

echo ODEzNTZjY2MwODIzMmIxMTU0Y2ExYmI5MmRlZjY4YWQwMGQ3ZDcwOTIzYmU3YjcyZWZmOTVlMTdiZTk5MzdkNS5leUpoYkdjaU9pSklVekkxTmlJc0luUjVjQ0k2SWtwWFZDSjkuZXlKbGVIQWlPakUxT0RreE5qRTVPRGw5LmpxNENXNk1WNHlUVkpVOWdBUzFqNkRCdE5qeVhQT3gxOHF5RnFfOWQ4WFkK |base64 -d
# then we get:
81356ccc08232b1154ca1bb92def68ad00d7d70923be7b72eff95e17be9937d5.eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE1ODkxNjE5ODl9.jq4CW6MV4yTVJU9gAS1j6DBtNjyXPOx18qyFq_9d8XY

将解码后的字符串复制到中，如下所示：

modules:
  edgeHub:
    token: 81356ccc08232b1154ca1bb92def68ad00d7d70923be7b72eff95e17be9937d5.eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE1ODkxNjE5ODl9.jq4CW6MV4yTVJU9gAS1j6DBtNjyXPOx18qyFq_9d8XY

四、使用 CRI 设置不同的 container runtime

① containerd

Docker 18.09 及更高版本自带 containerd ，因此无需手动安装，如果没有 containerd ，可以通过运行以下命令进行安装：

# Install containerd
apt-get update && apt-get install -y 

# Configure containerd
mkdir -p /etc/containerd
containerd config default > 

# Restart containerd
systemctl restart containerd

使用 Docker 自带的 containerd 时，默认情况下 cri 插件是不可使用的，需要更新 containerd 的配置，来使 KubeEdge 能够 containerd 作为它的 runtime：

# Configure containerd
mkdir -p /etc/containerd
containerd config default >

更新 edgecore 配置文件，为被作为 runtime 的 containerd 指定以下参数：

remoteRuntimeEndpoint: 
remoteImageEndpoint: 
runtimeRequestTimeout: 2
podSandboxImage: 
runtimeType: remote

默认情况下，cri 的 cgroup 驱动程序配置为 cgroupfs，如果不是这种情况，可以在中手动切换成 systemd：

modules:
  edged:
    cgroupDriver: systemd

设置 containerd 的配置文件（）中的 systemd_cgroup 为 true ，然后重新启动 containerd：

# 
systemd_cgroup = true

# Restart containerd
systemctl restart containerd

创建 nginx 应用程序，检查该服务容器含有 containerd 并位于边缘端：

kubectl apply -f $
 created

ctr  container ls
CONTAINER                                                           IMAGE                              RUNTIME
41c1a07fe7bf7425094a9b3be285c312127961c158f30fc308fd6a3b7376eab2        io.containerd.runtime.v1.linux

cri 不支持 multi-tenancy 但是 containerd 支持，因此默认情况下，容器的命名空间需要设置为 “”。

② CRI-O

请遵循 CRI-O安装指南来设置 CRI-O，如果边缘节点需要在 ARM 平台上运行，而发行版是 ubuntu18.04，那么可能需要构建二进制形式的源文件然后进行安装，因为 Kubic 存储库中没有针对此组合的 CRI-O 软件包：

git clone 
cd cri-o
make
sudo make install
# generate and install configuration files
sudo make install.config

遵循以下指导来配置 CNI 网络，设置 CNI，更新 edgecore 配置文件，为 CRI-O-based runtime 指定以下参数：

remoteRuntimeEndpoint: 
remoteImageEndpoint: 
runtimeRequestTimeout: 2
podSandboxImage: 
runtimeType: remote

默认情况下 CRI-O 使用 cgroupfs 作为一个 cgroup 的程序管理器，如果想替换成 systemd，请更新 CRI-O 配置文件（）：

# Cgroup management implementation used for the runtime.
cgroup_manager = "systemd"

如果在 ARM 平台上使用 pause 镜像，并且 pause 镜像不是 multi-arch 镜像，应该更新 pause 镜像，要配置 pause 镜像，更新 CRI-O 配置文件：

pause_image = ""

同时更新里面的 cgroup driver manager：

modules:
  edged:
    cgroupDriver: systemd

启动 CRI-O 和 edgecore 服务（假设两项服务均由 systemd 负责）：

sudo systemctl daemon-reload
sudo systemctl enable crio
sudo systemctl start crio
sudo systemctl start edgecore

创建应用程序，并检查 CRI-O 容器是在边缘端创建：

kubectl apply -f $
 created

# crictl ps
CONTAINER ID        IMAGE               CREATED             STATE               NAME                ATTEMPT             POD ID
41c1a07fe7bf7       f6d22dec9931b       2 days ago          Running             nginx               0                   51f727498b06f

③ Kata Containers

Kata Containers 是一个 container runtime，旨在解决多租户、不受信任的云环境中的安全挑战。但是多租户支持仍在 KubeEdge 的 backlog 中，如果下游定制 KubeEdge 已经支持多租户，那么 Kata Containers 是轻量级且安全的 container runtime 的理想选择。按照安装指南安装和配置容器和 Kata Containers。如果安装了“kata-runtime”，请运行以下命令以检查主机系统是否可以运行并创建 Kata 容器：

kata-runtime kata-check

RuntimeClass 是一项功能，用于选择自 containerdv1.2.0 以来受支持的container runtime配置，以用于运行 Pod 的容器。如果 containerd 版本高于 v1.2.0，则有两种选择来配置 containerd 以使用 Kata 容器： Kata Containers 作为 RuntimeClass； Kata Containers 作为不受信任的工作负载的 runtime。假设您已将 Kata Containers 配置为不受信任的工作负载的 runtime，为了验证它是否可以在边缘节点上运行，可以运行：

cat 
apiVersion: v1
kind: Pod
metadata:
  name: nginx-untrusted
  annotations:
    .untrusted-workload: "true"
spec:
  containers:
  - name: nginx
    image: nginx
    
    
kubectl create -f 

# verify the container is running with qemu hypervisor on edge side,
ps aux | grep qemu
root      3941  3.0  1.0 2971576 174648 ?      Sl   17:38   0:02 /usr/bin/qemu-system-aarch64

crictl pods
POD ID              CREATED              STATE               NAME                NAMESPACE           ATTEMPT
b1c0911644cb9       About a minute ago   Ready               nginx-untrusted     default             0

④ Virtlet

下载 CNI 插件安装包并解压它：

$ wget 

# Extract the tarball
$ mkdir cni
$ tar -zxvf  -C cni

$ mkdir -p /opt/cni/bin
$ cp ./cni/* /opt/cni/bin/

配置 CNI 插件：

$ mkdir -p /etc/cni/net.d/

$ cat > <<EOF
{
  "cniVersion": "0.3.1",
  "name": "containerd-net",
  "type": "bridge",
  "bridge": "cni0",
  "isGateway": true,
  "ipMasq": true,
  "ipam": {
    "type": "host-local",
    "subnet": "10.88.0.0/16",
    "routes": [
      { "dst": "0.0.0.0/0" }
    ]
  }
}
EOF

设置 VM runtime，使用脚本来设置 VM runtime，它利用 Arktos Runtime 安装包来启动三个容器：

vmruntime_vms
vmruntime_libvirt
vmruntime_virtlet

五、使用 Kubeflow 和 Volcano 实现典型 AI 训练任务

① Kubeflow 的诞生背景和运行 AI 计算任务面临的问题

Kubernetes 已经成为云原生应用编排、管理的事实标准，越来越多的应用选择向 Kubernetes 迁移。人工智能和机器学习领域天然的包含大量的计算密集型任务，开发者非常愿意基于 Kubernetes 构建 AI 平台，充分利用 Kubernetes 提供的资源管理、应用编排、运维监控能力。然而基于 Kubernetes 构建一个端到端的 AI 计算平台是非常复杂和繁琐的过程，它需要处理很多个环节。如下所示，除了熟知的模型训练环节之外还包括数据收集、预处理、资源管理、特性提取、数据验证、模型的管理、模型发布、监控等环节，对于一个 AI 算法工程师来讲，要做模型训练，就不得不搭建一套 AI 计算平台，这个过程耗时费力，而且需要很多的知识积累：

Kubeflow 诞生于 2017 年，Kubeflow 项目是基于容器和 Kubernetes 构建，旨在为数据科学家、机器学习工程师、系统运维人员提供面向机器学习业务的敏捷部署、开发、训练、发布和管理平台。它利用了云原生技术的优势，让用户更快速、方便的部署、使用和管理当前最流行的机器学习软件。目前 Kubeflow 1.0 版本已经发布，包含开发、构建、训练、部署四个环节，可全面支持企业用户的机器学习、深度学习完整使用过程，如下所示：

通过 Kubeflow 1.0，用户可以使用 Jupyter 开发模型，然后使用 fairing（SDK）等工具构建容器，并创建 Kubernetes 资源训练其模型。模型训练完成后，用户还可以使用 KFServing 创建和部署用于推理的服务器，再结合 pipeline（流水线）功能可实现端到端机器学习系统的自动化敏捷构建，实现 AI 领域的 DevOps。

② Kubernetes 存在的问题

既然有了 Kubeflow，是不是在 Kubernetes 上进行机器学习、深度学习就一帆风顺了呢？答案是否定的。我们知道 Kubeflow 在调度环境使用的是 kubernetes 的默认调度器，而 Kubernetes 默认调度器最初主要是为长服务设计的，对于 AI、大数据等批量和弹性调度方面还有很多的不足。主要存在以下问题：资源争抢问题：TensorFlow 的作业包含 Ps 和 Worker 两种不同的角色，这两种角色的 Pod 要配合起来完成整个作业，如果只是运行一种角色 Pod，整个作业是无法正常执行的，而默认调度器对于 Pod 调度是逐个进行的，对于 Kubeflow 作业 TFJob 的 Ps 和 Worker 是不感知的。在集群高负载（资源不足）的情况下，会出现多个作业各自分配到部分资源运行一部分 Pod，而又无法正执行完成的状况，从而造成资源浪费。以下为例，集群有 4 块 GPU 卡，TFJob1 和 TFJob2 作业各自有 4 个 Worker，TFJob1 和 TFJob2 各自分配到 2 个 GPU，但是 TFJob1 和 TFJob2 均需要 4 块 GPU 卡才能运行起来，这样 TFJob1 和 TFJob2 处于互相等待对方释放资源，这种死锁情况造成了 GPU 资源的浪费：

亲和调度问题：分布式训练中，Ps 和 Worker 存在很频繁的数据交互，所以 Ps 和 Worker 之间的带宽直接影响了训练的效率。Kubernetes 默认调度器并不考虑 Ps 和 Worker 的这种逻辑关系，Ps 和 Worker 是被随机调度的。如下图所示，2 个 TFJob（1 个 Ps + 2 Worker），使用默认调度器，有可能会出现（a）、（b）、（c）三种情况的任意一种情况，我们知道（c）才是最想要的调度结果。因为在©中，Ps 和 Worker 可以利用本机网络提供传输效率，缩短训练时间：

③ Volcano 批量调度系统加速 AI 计算的利器

Volcano是一款构建于 Kubernetes 之上的增强型高性能计算任务批量处理系统。作为一个面向高性能计算场景的平台，它弥补了 kubernetes 在机器学习、深度学习、HPC、大数据计算等场景下的基本能力缺失，其中包括 gang-schedule 的调度能力、计算任务队列管理、task-topology 和 GPU 亲和性调度。另外，Volcano 在原生 kubernetes 能力基础上对计算任务的批量创建及生命周期管理、fair-share、binpack 调度等方面做了增强，Volcano 充分解决了上文提到的 Kubeflow 分布式训练面临的问题：

④ Volcano 在华为云的应用：实现典型分布式 AI 训练任务

Kubeflow 和 Volcano 两个开源项目的结合充分简化和加速 Kubernetes 上 AI 计算进程，当前已经成为越来越多用户的最佳选择，应用于生产环境。Volcano 目前已经应用于华为云 CCE、CCI 产品以及容器批量计算解决方案。未来 Volcano 会持续迭代演进，优化算法、增强调度能力如智能调度的支持，在推理场景增加 GPU Share 等特性的支持，进一步提升 kubeflow 批量训练和推理的效率。登录 CCE 控制台，创建一个 CCE 集群，详情请参见购买 CCE 集群。在 CCE 集群上部署 Volcano 环境，单击左侧栏目树中的“插件管理”，在“插件市场”页签下单击 Volcano 插件下方的“安装插件”，在安装插件页面的“基本信息”步骤中选择要安装的集群和 Volcano 插件版本，单击“下一步：规格配置”：

Volcano 插件无可配置参数，直接单击“安装”，等待安装任务完成。安装 kfctl 工具并设置环境变量，环境变量设置如下：

export KF_NAME=<your choice of name for the Kubeflow deployment>
export BASE_DIR=<path to a base directory>
export KF_DIR=${BASE_DIR}/${KF_NAME}
export CONFIG_URI=""

kfctl 安装：下载 kfctl：

tar -xvf kfctl_v1.0.2_<platform>
chmod +x kfctl
mv kfctl /usr/local/bin/

部署 kubeflow：

mkdir -p ${KF_DIR}
cd ${KF_DIR}
kfctl apply -V -f ${CONFIG_URI}

下载 kubeflow/examples 到本地并根据环境选择指南，命令如下：

yum install git
git clone

安装 python3：

wget 
tar -zxvf 
cd Python-3.6.8 ./configure
make make install

安装完成后执行如下命令检查是否安装成功：

python3 -V 
pip3 -V

安装 jupyter notebook 并启动，命令如下：

pip3 install jupyter notebook
jupyter notebook --allow-root

Putty 设置 tunnel，远程连接 notebook，连接成功后浏览器输入 localhost:8000，登录 notebook。

根据 jupyter 的指引，创建分布式训练作业，通过简单的设置 schedulerName 字段的值为“volcano”，启用 Volcano 调度器：

kind: TFJob
metadata:
  name: {train_name}  
spec:
  schedulerName: volcano
  tfReplicaSpecs:
    Ps:
      replicas: {num_ps}
      template:
        metadata:
          annotations:
             "false"
        spec:
          serviceAccount: default-editor
          containers:
          - name: tensorflow
            command:
            ...
            env:
            ...
            image: {image}
            workingDir: /opt
          restartPolicy: OnFailure
    Worker:
      replicas: 1
      template:
        metadata:
          annotations:
             "false"
        spec:
          serviceAccount: default-editor
          containers:
          - name: tensorflow
            command:
            ...
            env:
            ...
            image: {image}
            workingDir: /opt
          restartPolicy: OnFailure

提交作业，开始训练：

kubectl apply -f

等待训练作业完成，通过 Kubeflow 的 UI 可以查询训练结果信息。至此就完成了一次简单的分布式训练任务，Kubeflow 的借助 TFJob 简化了作业的配置。Volcano 通过简单的增加一行配置就可以让用户启动组调度、Task-topology 等功能来解决死锁、亲和性等问题，在大规模分布式训练情况下，可以有效的缩短整体训练时间。
原文地址1：https://blog.csdn.net/yyyqqq_/article/details/135288540
参考资料：python中用turtle画一个圆形 https://blog.csdn.net/SXIAOYAN_/article/details/140061099