从基础到实践玩转边缘计算平台KubeEdge【与云原生的故事】

举报
龙哥手记 发表于 2022/04/21 21:20:55 2022/04/21
【摘要】 优秀的边缘计算框架

【摘要】本文的主要内容有：由容器必须掌握知识点，以及边缘计算基础理论和具体 kubeEdge 常用操作构成。这篇博文文章的定位是：温习，查阅，很适合接触的新手学习。这里也送给大家一句话 👍：“流水不争先后，争的是滔滔不绝…”

本文的主要内容有：

  • 一 容器先搞清楚
  • 二 边缘计算了解下
  • 三 为什么要选择KubeEdge
  • 四 KubeEdge的优势
  • 五 该如何部署容器

一 🧊 容器先搞清楚

1 定义

到底什么是容器呢？

先来看百科咋说

上面说的很啰嗦并且晦涩，你记住我的话理解就可以，就是“ 支持自定义的一种完全隔离与可复用的资源 ”。
简单来说，容器（container）本质就是一个 Linux 进程，它共享主机的 CPU、内存等资源，为分层结构，它有自己的 IP 地址，并且通过端口映射方式能与公网通信（也就是说容器 IP 映射到主机中能访问公网的 IP 地址），容器就是拥有不同 IP 地址的 Linux 进程而已。

相信你理解的八级不离十。再具体点使用上来描述

说白点就是一个 Docker 镜像（iimage）的运行实例嘛。然后你可以打包成自己的引用以及依赖包到一个可移植的镜像中然后发布到市场里面，那么任何流行的 Linux 或 Windows 机器上，也可以下载实现虚拟化。并且容器是完全使用沙箱机制，相互之间不会有任何接口，性能也提高喽。

2 起源

ok,我们来说下它的起源

基于万恶之源 Linux(手动狗头)，它是一种内核虚拟化技术（LXC），可以提供轻量级的虚拟化，以便隔离进程和资源。

这个地方就绕不开虚拟化，就是对硬件的虚拟，实现对 CPU，内存网络，存储等资源的共享，每个虚拟化需要单独安装操作系统，通过虚拟机监视器监视每个虚拟机的运行状态；而容器时实现对操作系统的虚拟化，每个容器不需要单独安装操作系统，它是运行在操作系统之上。

3 容器由两部分组成

  • （1）应用程序本身。

  • （2）依赖：比如应用程序需要的库或其他软件容器在 Host OS 的用户空间中运行，与操作系统的其他进程隔离。容器部署和启动速度更快、开销更小，也更容易迁移。

4 容器与虚拟机之间的区别

  • 1 虚拟机是操作系统级别的隔离；容器是进程级别的隔离。
    -2 虚拟机需要有完整的操作系统；容器不需要客户机操作系统。
  • 3 同一虚拟机上的应用程序并没有隔离，容器镜像的轻量性和不可变性。
  • 4 虚拟机被 vcenter Server、RHV Manager 等工具管理；容器被由 Kubernetes、Apache、Docker Swarm Mesos 等工具管理。
  • 5 虚拟机包括应用程序和整个操作系统，虚拟机占用空间大，资源消耗高，可移植性差； 容器只包含应用程序和它运行时需要的环境，比较轻量，占用空间小，可移植性强。

5 容器的优点

  • 快速创建/部署应用：与 VM 虚拟机相比，容器镜像的创建更加快速，启动速度快。
  • 持续开发、集成和部署：提供可靠且频繁的容器镜像构建/部署，并使用快速和简单的回滚(由于镜像不可变性)。
  • 开发和运行相分离：在 build 或者 release 阶段创建容器镜像，使得应用和基础设施解耦。
  • 开发，测试和生产环境一致性：在本地或外网（生产环境）运行的一致性。云平台或其他操作系统：可以在 Ubuntu、RHEL、 CoreOS、on-prem、Google Container Engine 或其它任何环境中运行。容器封装了所有运行应用程序所必需的相关的细节比如应用依赖以及操作系统，所以镜像从一个环境移植到另一个环境更加灵活。
  • 同一个镜像可以在 Windows 或 Linux 或者 开发、测试或 stage 环境中运行
  • Loosely coupled，分布式，弹性，微服务化：应用程序分为更小的、独立的部件，可以动态部署和管理，提高生产力。
  • 标准化： 大多数容器基于开放标准，可以运行在所有主流 Linux 发行版、Microsoft 平台等等。
  • 安全：容器之间的进程是相互隔离的，其中的基础设施亦是如此。这样其中一个容器的升级或者变化不会影响其他容器。

6. 容器的缺点

  • 复杂性增加，管理生产环境中成百上千的容器极具挑战性。可以使用 Kubernetes 和 Mesos 等工具管理具有一定规模数量的容器。
  • 原生 Linux 支持：大多数容器技术，比如 Docker，基于 Linux 容器（LXC），相比于在原生 Linux 中运行容器，在 Microsoft 环境中运行容器略显笨拙，并且日常使用也会带来复杂性。
  • 不成熟：容器技术在市场上是相对新的技术，需要时间来适应市场。开发者中的可用资源是有限的，如果某个开发者陷入某个问题，可能需要花些时间才能解决问题。
  • 由于所有容器都是与宿主机共用内核的，容器与容器之间的隔离性就会差很多。
  • 容器里面是不存放数据的，容器里面的数据会随着容器的生命周期而消失，如果想要持久化的存储，必须要依靠外部的存储设备。

7 容器分类

  • 1）操作系统容器

把操作系统内核虚拟化，可以允许多个独立用户空间的存在，而不是只有一个。这些实例有时会被称为容器、虚拟引擎、虚拟专用服务器或是 jails（FreeBSD jail 或者 chroot jail）。从运行在容器中的程序角度来看，这些实例就如同真正的计算机。
要创建操作系统容器，我们可以利用容器技术，如 LXC，OpenVZ，Linux VServer，BSD Jails 和 Solaris 区域。

7）应用容器

应用程序容器旨在作为单个进程进行打包和运行服务，而在 OS 容器中，可以运行多个服务和进程。
应用容器技术（容器管理器）：Docker 和 Rocket。

二 边缘计算了解下


“边缘计算”究竟是何方神圣

其实边缘计算出现的时间并不长，这一概念有许多人进行过概括，范围界定和阐述各有不同，甚至有些是重复和矛盾的，就个人而言，比较推崇 OpenStack（是一个由 NASA 和 Rackspace 合作研发并发起的，以 Apache 许可证授权的自由软件和开放源代码项目）社区的定义概念如下

“边缘计算是为应用开发者和服务提供商在网络的边缘侧提供云服务和 IT 环境服务；目的是在靠近数据输入或用户的地方提供计算、存储和网络带宽”。

说白了：边缘计算本质上是还是一种服务，就类似于云计算、大数据服务，但这种服务非常靠近用户；为什么要这么近？目的是为了让用户感觉到刷什么内容都特别快。

边缘计算着重要解决的问题，是传统云计算（或者说是中央计算）模式下存在的高延迟、网络不稳定和低带宽问题。举一个现实的例子，几乎所有人都遇到过手机 APP 出现 404 错误的情况 ，这样的一些错误出现就和网络状况、云服务器带宽限制有关系。由于资源条件的限制，云计算服务不可避免收到高延迟、和网络不稳定带来的影响，但是通过将部分或者全部处理程序迁移至靠近用户或数据收集点，边缘计算能够大大减少在云中心模式站点下给应用程序所带来的影响。

边缘计算,和雾计算同一时间出现的，事实上两个概念之间有重叠的地方。这两个词是从 2011 年开始出现，如今已经成为了巨头的投资热点。先看看世界上的科技巨头们选择的方向吧：

  • Arm、Cisco、Dell、Intel、Microsoft、普林斯顿大学共同投资创办的雾计算研究项目 OpenFog；
  • Orange (法国电信) 与 Inria(法国国立计算机及自动化研究院)共同主导的雾计算与大规模分布式云研究项目 Discovery；
  • 华为的“全面云化”战略， EC-IOT， 2016 年成立边缘计算产业联盟；
  • Intel 的“Cloud Computing at the Edge”项目；
  • NTT 的“Edge Computing”项目， AT&T 的 “Cloud 2.0”项目；
  • 亚马逊 AWS 发布的 GreenGrass 项目（边缘计算代号）；
  • 微软 Azure 发 IOT Edge 项目，重点发展边缘计算项目；
  • 谷歌发布的 IOT Core 项目；
  • 阿里云发布的 LinkEdge 项目。

那么从 2016 到现在，巨头们已经在边缘计算的路上展开了激烈的角逐, 赛道已经非常的拥挤

下面是一个边缘计算网络的概念图,它是连接设备和云端的重要中间环节。

边缘计算起源于广域网内搭建虚拟网络的需求，具体说运营商们需要一个简单的、类似于云计算的管理平台，于是微缩板的云计算管理平台开始进入了市场。
从这一点来看，边缘计算其实是脱胎于云计算的。随着这一微型平台的不断演化，尤其是得益于虚拟化技术（指通过虚拟化技术将一台计算机虚拟为多台逻辑计算机。在一台计算机上同时运行多个逻辑计算机，每个逻辑计算机可运行不同的操作系统，并且应用程序都可以在相互独立的空间内运行而互不影响，从而显著提高计算机的工作效率。）的不断发展，人们发现这一平台有着管理成千上万边缘节点的能力，且能满足多样化的场景需求，经过不同厂商对这一平台不断改良，并加入丰富的功能，使得边缘计算开始进入了发展的快车道。

说了这么多总结一下这个边缘计算的优点：

  • 低延迟：计算能力部署在设备侧附近，设备请求实时响应；
  • 低带宽运行：将工作迁移至更接近于用户或是数据采集终端的能力能够降低站点带宽限制所带来的影响。尤其是当边缘节点服务减少了向中枢发送大量数据处理的请求时。
  • 隐私保护：数据本地采集，本地分析，本地处理，有效减少了数据暴露在公共网络的机会，保护了数据隐私。

三 为什么选择 KubeEdge

KubeEdge 是一个开源系统，功能是原生容器化应用编排和设备管理扩展到边缘主机。它建立在 Kubernetes 之上，为云和边缘之间的网络、应用程序部署和元数据同步提供核心基础架构支持。它还支持 MQTT，并允许开发人员编写自定义逻辑并在边缘启用资源受限的设备通信。KubeEdge 由云部分和边缘部分组成。边缘和云部分现在都是开源的。

四 KubeEdge的优势


主要包括以下

  • 1 边缘计算

通过在边缘运行业务逻辑，可以在生成数据的地方保护和处理大量数据。这很大降低了边缘和云之间的网络带宽要求和消耗。这提高了响应能力，降低了成本，并保护了客户的数据隐私。

  • 2 简化开发

开发人员可以编写常规的基于 HTTP 或 MQTT 的应用程序，将就可以把应用容器化，然后在任何地方运行它们——无论是在边缘还是在云端——以更合适的方式运行。

  • 2 Kubernetes 原生支持

使用 KubeEdge，用户可以在边缘节点上编排应用程序、管理设备以及监控应用程序和设备状态，就像云中的传统 Kubernetes 集群一样。

  • 3 丰富的应用

很容易将现有的复杂机器学习、图像识别、事件处理和其他高级应用程序获取和部署到边缘节点上面。

KubeEdge 由以下组件组成

  • Edged：在边缘节点上运行并管理容器化应用程序的代理。
  • EdgeHub：一个 Web 套接字客户端，负责与边缘计算的云服务交互（如 KubeEdge 架构中的边缘控制器）。这包括将云端资源更新同步到边缘，并将边缘端主机和设备状态更改报告到云端。
  • CloudHub：一个 Web 套接字服务器，负责在云端观察变化，缓存并发送消息到 EdgeHub。
  • EdgeController：一个扩展的 kubernetes 控制器，它管理边缘节点和 pod 元数据，以便可以将数据定位到特定的边缘节点。
  • EventBus：一个 MQTT 客户端，用于与 MQTT 服务器（mosquitto）交互，为其他组件提供发布和订阅功能。
  • DeviceTwin：负责存储设备状态并将设备状态同步到云端。它还为应用程序提供查询接口。
  • MetaManager： edged 和 edgehub 之间的消息处理器。它还负责在轻量级数据库 (SQLite) 中存储/检索元数据。

五 如何部署它

1 安装 keadm

运行以下命令一键完成。


# docker run --rm kubeedge/installation-package:v1.10.0 cat /usr/local/bin/keadm > /usr/local/bin/keadm && chmod +x /usr/local/bin/keadm

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

默认情况下，边缘节点需要可以访问端口 10000 和云核心中的端口。10002

3 进行初始化

keadm init 将安装 cloudcore，生成证书并安装 CRD。它还提供了一个可以设置特定版本的标志。

重要提示

    1. kubeconfig 或 master 至少其中一项必须配置正确，才能用于验证 k8s 集群的版本等信息。
    1. 请确保边缘节点可以使用云节点的本地 IP 连接云节点，或者您需要使用–advertise-address 标志指定云节点的公共 IP。
    1. –advertise-address（仅从 1.3 版本开始有效）是云端暴露的地址（将添加到 CloudCore 证书的 SAN 中），默认值为本地 IP。
    1. keadm init 以二进制进程部署 cloudcore 作为系统服务，如果你想将 cloudcore 部署为容器，请参考 keadm beta 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:  /var/log/kubeedge/cloudcore.log

4 keadm beta init

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

举个例子:


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

重要提示

    1. 为 cloudcore helm 图表设置标志–set key=value 可以参考 KubeEdge Cloudcore Helm Charts README.md。
    1. 您可以从 Keadm 的内置配置文件之一开始，然后根据您的特定需求进一步自定义配置。目前，内置的配置文件关键字是 version. 参考version.yaml，您可以在此处创建自定义值文件，并添加–profile version=v1.9.0 --set key=value 使用此配置文件的标志。

– 3. external-helm-rootflag 提供了一个特性函数来安装外部 helm 图表，如 edgemesh。

例子：


# keadm beta init --set server.advertiseAddress="THE-EXPOSED-IP" --set server.nodeName=allinone  --kube-config=/root/.kube/config --force --external-helm-root=/root/go/src/github.com/edgemesh/build/helm --profile=edgemesh

如果您熟悉 helm chart 安装，请看 KubeEdge Helm Charts

5 keadm beta 清单生成

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

例子：


# keadm beta manifest generate --advertise-address="THE-EXPOSED-IP" --kube-config=/root/.kube/config > kubeedge-cloudcore.yaml

添加 –skip-crds 标志以跳过输出 CRD

6 设置边缘端（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

重要提示

    1. –cloudcore-ipportflag 是强制性标志。
    1. 如果要自动为边缘节点申请证书，–token 则需要。
    1. 云端和边缘使用的 kubeEdge 版本应该相同。

输出：


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

您现在还可以使用 keadm beta join 更好的集成步骤。

7 启用 kubectl logs 功能

在部署 metrics-server 之前，kubectl logs 必须激活功能：

确保您可以找到 kubernetesca.crt 和 ca.key 文件。如果你通过 设置你的 kubernetes 集群 kubeadm，这些文件将在/etc/kubernetes/pki/dir 中。

ls /etc/kubernetes/pki/

设置 CLOUDCOREIPS 环境。环境变量设置为指定 cloudcore 的 IP 地址，如果您有高可用性集群，则设置为 VIP。

export CLOUDCOREIPS="192.168.0.139"

（警告：要继续工作，必须使用相同的终端，否则必须再次键入此命令。）使用以下命令检查环境变量：

echo $CLOUDCOREIPS

在云节点上为 CloudStream 生成证书，但是生成文件不在 中/etc/kubeedge/，我们需要从 GitHub 克隆的 git 存储库中复制它。将用户更改为 root：

sudo su

从原始克隆存储库复制证书生成文件：

cp $GOPATH/src/github.com/kubeedge/kubeedge/build/tools/certgen.sh /etc/kubeedge/

将目录更改为 kubeedge 目录：

cd /etc/kubeedge/

从 certgen.sh 生成证书

/etc/kubeedge/certgen.sh stream

需要在主机上设置 iptables。（此命令应在每个 apiserver 部署的节点上执行。）（在这种情况下，这是主节点，并以 root 执行此命令。）在每个 apiserver 运行的主机上运行以下命令：

注意：您需要先获取 configmap，其中包含所有 cloudcore ips 和隧道端口。

kubectl get cm tunnelport -nkubeedge -oyaml

apiVersion: v1
kind: ConfigMap
metadata:
annotations:
tunnelportrecord.kubeedge.io: '{"ipTunnelPort":{"192.168.1.16":10350, "192.168.1.17":10351},"port":{"10350":true, "10351":true}}'
creationTimestamp: "2021-06-01T04:10:20Z"
...

Then set all the iptables for multi cloudcore instances to every node that apiserver runs. The cloudcore ips and tunnel ports should be get from configmap above.


iptables -t nat -A OUTPUT -p tcp --dport $YOUR-TUNNEL-PORT -j DNAT --to $YOUR-CLOUDCORE-IP:10003
iptables -t nat -A OUTPUT -p tcp --dport 10350 -j DNAT --to 192.168.1.16:10003
iptables -t nat -A OUTPUT -p tcp --dport 10351 -j DNAT --to 192.168.1.17:10003

如果不确定是否设置了iptables，并且希望清除所有iptables。（如果您错误地设置了iptables，它将阻止您使用’kubectl logs’功能）

以下命令可用于清理iptables：

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

请注意，此部分可以由iptablesmanager组件完成，无需手动添加。参考 cloudcore helm values.
修改 cloudcore /etc/kubeedge/config/cloudcore.yaml 和/etc/kubeedge/config/edgecore.yamledgecore。将 cloudStream 和 edgeStream 设置为 enable: true. 将服务器 IP 更改为 cloudcore IP（与 $CLOUDCOREIPS 相同）。

在 cloudcore 中打开 YAML 文件

sudo nano /etc/kubeedge/config/cloudcore.yaml

修改以下部分（enable: true）中的文件：

cloudStream:
enable: true
streamPort: 10003
tlsStreamCAFile: /etc/kubeedge/ca/streamCA.crt
tlsStreamCertFile: /etc/kubeedge/certs/stream.crt
tlsStreamPrivateKeyFile: /etc/kubeedge/certs/stream.key
tlsTunnelCAFile: /etc/kubeedge/ca/rootCA.crt
tlsTunnelCertFile: /etc/kubeedge/certs/server.crt
tlsTunnelPrivateKeyFile: /etc/kubeedge/certs/server.key
tunnelPort: 10004

在 edgecore 中打开 YAML 文件：

sudo nano /etc/kubeedge/config/edgecore.yaml

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

edgeStream:
enable: true
handshakeTimeout: 30
readDeadline: 15
server: 192.168.0.139:10004
tlsTunnelCAFile: /etc/kubeedge/ca/rootCA.crt
tlsTunnelCertFile: /etc/kubeedge/certs/server.crt
tlsTunnelPrivateKeyFile: /etc/kubeedge/certs/server.key
writeDeadline: 15

重启所有 cloudcore 和 edgecore。

sudo su

进程模式下的 cloudCore

pkill cloudcore
nohup cloudcore > cloudcore.log 2>&1 &

或者 Kubernetes 部署模式下的 cloudCore：

kubectl -n kubeedge rollout restart deployment cloudcore

边缘核心：

systemctl restart edgecore.service

如果您无法重新启动 edgecore，请检查是否是因为 kube-proxy 并杀死它。 kubeedge 默认拒绝它，我们使用一个名为 edgemesh 的 succedaneum

注意：重要的是避免 kube-proxy 部署在 edgenode 上。有两种方法可以解决：

  • 1 通过调用添加以下设置 kubectl edit daemonsets.apps -n kube-system kube-proxy：
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms: - matchExpressions: - key: node-role.kubernetes.io/edge
operator: DoesNotExist

如果您仍想运行 kube-proxy，请通过在以下位置添加 env 变量来要求 edgecore 不要检查环境 edgecore.service：

sudo vi /etc/kubeedge/edgecore.service

将以下行添加到 edgecore.service 文件中：

Environment="CHECK_EDGECORE_ENVIRONMENT=false"

最终文件应如下所示

Description=edgecore.service

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

[Install]
WantedBy=multi-user.target

8 支持云中的 Metrics-server

该功能点的实现复用了 cloudstream 和 edgestream 模块。因此，您还需要执行 Enable kubectl logsFeature 的所有步骤。

由于边缘节点和云节点的 kubelet 端口不一样，目前发布的 metrics-server(0.3.x)版本不支持端口自动识别（0.4.0 的特性），需要手动编译现在自己从主分支中获取图像。

Git 克隆最新的指标服务器存储库：

git clone https://github.com/kubernetes-sigs/metrics-server.git

转到指标服务器目录：

cd metrics-server

制作泊坞窗图像：

make container

检查你是否有这个 docker 镜像：

docker images

存储库 标签 图像 ID 创造 尺寸
gcr.io/k8s-staging-metrics-serer/metrics-serer-amd64 6d92704c5a68cd29a7a81bce68e6c2230c7a6912 a24f71249d69 19 秒前 57.2MB
指标-服务器-kubeedge 最新的 aef0fa7a834c 28 秒前 57.2MB
确保通过使用其 IMAGE ID 更改图像的标签，以便与 yaml 文件中的图像名称进行压缩。

docker tag a24f71249d69 metrics-server-kubeedge:latest

应用部署 yaml。具体部署文档可以参考https://github.com/kubernetes-sigs/metrics-server/tree/master/manifests。

注意：下面的那些 iptables 必须在机器上应用（确切地说是网络命名空间，所以 metrics-server 也需要在 hostnetwork 模式下运行）metric-server 运行在上面。

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

（为了通过 cloudcore 和 edgecore 之间的隧道引导来自 edgecore:10250 的度量数据请求，iptables 至关重要。）

在部署 metrics-server 之前，您必须确保将其部署在部署了 apiserver 的节点上。在这种情况下，那是主节点。因此，需要通过以下命令使主节点可调度：

kubectl taint nodes --all node-role.kubernetes.io/master-

然后，在 deployment.yaml 文件中，必须指定 metrics-server 部署在主节点上。（选择主机名作为标记的标签。）在 metrics-server-deployment.yaml

    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              #Specify which label in [kubectl get nodes --show-labels] you want to match
              - key: kubernetes.io/hostname
                operator: In
                values:
                #Specify the value in key
                - charlie-latest

重要提示： 1. Metrics-server 需要使用 hostnetwork 网络模式。

使用自己编译的镜像，将 imagePullPolicy 设置为 Never。

为 Metrics-server 启用 –kubelet-use-node-status-port 的功能

这些设置需要写在部署 yaml (metrics-server-deployment.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

9 总结下

KubeEdge 是一个开源的边缘计算平台，它在Kubernetes原生的容器编排和调度能力之上，实现了 云边协同、计算下沉、海量边缘设备管理、边缘自治 等能力。 在追求边缘极致轻量化的同时，结合云原生生态的众多优势，解决当前智能边缘领域面临的挑战。

未来展望

随着v1.4版本的发布，KubeEdge提供了更完备的边缘应用监控管理与边缘设备管理能力，更稳定可靠的云边协同传输机制，更加友好的用户体验，以及更加友好的社区贡献者体验。感谢华为、中国联通、浙江大学SEL实验室、ARM等组织的贡献，也感谢所有社区贡献者的支持！
社区将在后续版本中进一步提升KubeEdge的用户使用体验与稳定性，打造最好用的智能边缘计算平台。

【版权声明】本文为华为云社区用户原创内容，转载时必须标注文章的来源（华为云社区）、文章链接、文章作者等基本信息， 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容，举报邮箱： cloudbbs@huaweicloud.com
云原生 云计算 容器
  • 点赞
  • 收藏
  • 关注作者

评论（0）

0/1000
抱歉，系统识别当前为高风险访问，暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称，即可参与社区互动！

*长度不超过10个汉字或20个英文字符，设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符，设置后3个月内不可修改。

确认 取消

加入云驻计划，成为创作者

  • 华为云周边好礼
  • 免费体验产品
  • 特殊身份标识
  • 线下官方门票
  • 内部专家零距离
  • 与10000+优质创作者共同成长
立即加入