Решение Edge Container Cloud

1. Крайнее вычисление и K8S

1.1 Анализ отрасли краевого вычисления

1.1.1 Эволюция архитектуры вычислительных систем за 60 лет

1960-1980: Монолитная архитектура вычислений, доминировавшая в закрытых сетях и крупных приложениях.
1980-2000: Распределенная архитектура вычислений, доминировавшая в открытых сетях и малых клиентских приложениях, что привело к эре PC-интернета.
2000-2020: Централизованная архитектура вычислений, основанная на облачных вычислениях, с клиентами в виде PC, Android и iOS, что привело к эре мобильного интернета.
2020-?: Будущее будет характеризоваться унифицированной архитектурой вычислений, сочетающей централизацию и децентрализацию, что приведет к эре промышленного интернета.

Облачные вычисления и краевое вычисление не являются взаимоисключающими. Централизованные облачные центры обработки данных продолжат существовать, и их общая емкость может продолжить расти. Однако новые требования (например, Интернет вещей, промышленный интернет, интернет автомобилей) и требования к услугам с минимальной задержкой в эпоху 5G будут способствовать развитию краевого вычисления.

С увеличением плотности вычислений и расширением их распространения границы между централизацией и децентрализацией станут менее четкими.#### 1.1.2 5G и краевое вычисление взаимно поддерживают друг друга

Всплеск краевого вычисления, с одной стороны, связан с постепенным усовершенствованием IT-сетевых технологий, таких как SDN/SD-WAN, а с другой стороны, с появлением эры 5G, что подтверждает ценность краевого вычисления. Краевое вычисление компенсирует недостатки облачных вычислений, которые не могут обеспечить поддержку для 5G-сетей:

Усиленная мобильная пропускная способность (eMBB): Краевое вычисление может сэкономить 35% обратного трафика, уменьшая нагрузку на транспортную и центральную сети.
Низкая задержка и высокая надежность (uRLLC): Краевое вычисление может уменьшить обратную физическую задержку на OnClickListener 50%, удовлетворяя требования пользователей к чувствительности к задержке.
Массовое подключение терминалов (mMTC): К 2025 году в мире будет около 9 миллиардов мобильных подключений и 250 миллиардов подключений IoT. Сгенерированные огромные объемы данных, не связанных с бизнесом, могут быть отфильтрованы на крае, не требуя их передачи на центральную обработку. Кроме того, можно повысить вычислительную мощность терминалов, переместив ее на крае, что позволит устройствам иметь только способность к потоковому воспроизведению, тем самым снижая их стоимость.

#### 1.1.3 5G + краевое вычисление способствуют обновлению промышленного интернета

Известная исследовательская организация по краевому вычислению State of the Edge опубликовала последний отчет по краевому вычислению "State of the Edge 2020". В отчете приведены прогнозы рынка краевого вычисления.

В течение следующих 10 лет глобальные затраты на капитальные инвестиции (CAPEX) в краевое вычисление будут расти со среднегодовым темпом 35%. С 2020 по 2028 год глобальные затраты на капитальные инвестиции (CAPEX) в краевое вычисление составят около 700 миллиардов долларов. К 2028 году рынок краевого вычисления будет в основном доминировать потребительскими приложениями. С развитием продуктов, основанных на платформах краевого вычисления, количество и разнообразие сценариев применения краевого вычисления, вероятно, значительно увеличатся. 11 отраслей занимают 80-85% рынка краевого вычисления:

Телекоммуникационные операторы
Корпоративные IT
Производство
Интеллектуальные электрические сети
Умные города
Розничная торговля
Здравоохранение
Транспорт
Мобильные услуги для потребителей
Жилищные услуги для потребителей
Коммерческие беспилотные летательные аппараты

1.2 Архитектура краевого вычисления

1.2.1 MEC-краевая облако

Кластерная форма: существует несколько кластеров краевой облако, каждый кластер автономен
Вход для экземпляров приложений краевой облако: MEAO, многокластерное управление
Основные требования: ориентированы на потребности 5G
Стоимость: высокая
Безопасность данных: упор на конфиденциальность

1.2.2 Облачное краевое вычисление

Кластерная форма: существует только один кластер, центральное облако запускает центральный мастер, краевое облако запускает несколько узлов краевой облако, подключенных к одному мастеру
Вход для экземпляров приложений краевой облако: центральный мастер, многонодное управление
Основные требования: ориентированы на потребности CDN, IoT и других интернет-приложений
Стоимость: низкая
Безопасность данных: данные не защищены

Облачное краевое вычисление является расширением центрального облака на краевой стороне, логически являясь частью центрального облака. Краевая сторона должна тесно взаимодействовать с центральным облаком. Например:- Huawei Cloud KubeEdge

Alibaba Cloud OpenYurt
Tencent Cloud SuperEdge

Основные требования:

Передача краевой вычислительной системы как расширения облачной вычислительной системы
Фокус на гибридных облачных сценариях, где программные стеки на облаке поглощают рынок краевой вычислительной системы.

Техническая архитектура:

Облачно-краевая, облачно-краевая кооперативная архитектура
Снижение вычислительных узлов до краевой области

1.3 Проблемы краевых решений

1.3.1 Отсутствие феноменальных краевых приложений

Основная причина: противоречие между передовыми базовыми технологиями 5G и отставанием в прикладных технологиях

Технологические стеки, адаптированные для высокоскоростных мобильных промышленных интернет-устройств, еще не сформированы
5G микросекундная задержка и миллисекундная задержка в下沉UPF
Краевое облако для игр имеет преимущество только при рендеринге на больших экранах, бизнес-модель требует подтверждения
Приложения AI ограничены в области распознавания образов, и оптимизация моделей является искусством, а не инженерией
AR/VR ограничены физическими аппаратными средствами
Умные спортивные сооружения IoT ограничены B2B, кривая повторного использования технологических стеков резко возрастает
Цифровые люди/метавселенная остаются концептуальными акциями

1.3.2 Краевое облако должно поддерживать гетерогенные аппаратные средства

VM против Pod
Процессор: ARM/X86/RISC-V/Loongson...
Операционная система: CentOS/OpenEuler/Кунлунь
GPU
SRIOV/DPDK
RT Kernel
Хранилище
Централизованное управление против автономной работы

1.3.3 K8S для края

Архитектура K8S

Архитектура Kata

Архитектура KubeVirt

2. Решение K3S

2.1 Основные понятия K3S

2.1.1 Что такое K3S

Документация K3S

Официальный сайт Kubernetes
Официальная документация KubernetesKubernetes-кластеры обладают отличными преимуществами автоматизации управления большими сервисами (автоматическое восстановление / масштабирование / балансировка нагрузки / регистрация и обнаружение сервисов / развертывание), но требуют значительных ресурсов. Многие функции являются избыточными для определенных сценариев, поэтому K3S был создан как легковесная версия Kubernetes, оптимизированная для краевых вычислений и Интернета вещей.

K3S имеет следующие улучшения:- Упакован в единую исполняемую файлу.

Использует легковесное хранилище на основе sqlite3 в качестве стандартного механизма хранения. Поддерживает использование etcd3, MySQL и PostgreSQL в качестве механизмов хранения.
Упакован в простой запускающий скрипт, который обрабатывает сложные TLS-опции.
По умолчанию безопасен и имеет разумные настройки по умолчанию для легковесных сред.
Добавлены простые, но мощные встроенные функции, такие как: локальный провайдер хранения, балансировщик нагрузки сервисов, Helm контроллер и Traefik Ingress контроллер.
Все компоненты управления кластером Kubernetes упакованы в единую исполняемую файлу и процесс, что позволяет K3S автоматизировать и управлять сложными операциями кластера, такими как распространение сертификатов.
Минимизирует внешние зависимости, K3S требует только ядра и монтирование cgroup. Пакет K3S требует следующих зависимостей:
- containerd
- Flannel
- CoreDNS
- CNI
- Утилиты хоста (iptables, socat и т.д.)
- Ingress контроллер (Traefik)
- Встроенный балансировщик нагрузки сервисов (service load balancer)
- Встроенный контроллер политики сети (network policy controller)K3S предназначен для:
Работы на крае - Edge / Интернета вещей - IoT / встроенных K8S
CI / DevOps

2.2 Развертывание K3S

2.2.1 Одноузловой архитектурный подход

Архитектура одноузловой кластеры K3s показана на приведённой ниже схеме. В этом кластере есть одиночный узел K3s сервера с встроенной базой данных SQLite.

В этой конфигурации каждый узел агента регистрируется на одном и том же серверном узле. Пользователи K3s могут управлять ресурсами Kubernetes, вызывая API K3s на серверном узле. Внешний трафик направляется через Traffic и распределяется с помощью loadBalance.

2.2.2 Подготовка к развертыванию

См. конфигурационные изменения K3S

2.2.3 Одноузловой подход к развертыванию

Узел	CPU	Оперативная память	Жесткий диск	Количество	ОС
server/agent	>2 ядра	>1 ГБ	>10 ГБ	1	centos7.x

K3s по умолчанию использует containerd в качестве CRI, но мы будем использовать более знакомый docker в качестве CRI для кластера. Сначала установим docker.

yum install -y yum-utils
yum-config-manager --add-repo http://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo
yum makecache fast
yum install docker-ce-19.03.9 -y
mkdir -p /etc/docker
echo '{"registry-mirrors": ["http://hub-mirror.c.163.com"]}'>/etc/docker/daemon.json
systemctl enable --now docker

Установка скрипта``` bash

curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="--docker" sh -

Из-за ограниченного доступа к сети в Китае, вышеупомянутый скрипт обычно не работает. Рекомендуется использовать следующий скрипт с ускоренной установкой для Китая.

curl -sfL http://rancher-mirror.cnrancher.com/k3s/k3s-install.sh | INSTALL_K3S_MIRROR=cn INSTALL_K3S_EXEC="--docker" sh -


```log
...
[INFO]  Создание символической ссылки /usr/local/bin/kubectl на k3s
[INFO]  Создание символической ссылки /usr/local/bin/crictl на k3s
[INFO]  Пропуск создания символической ссылки /usr/local/bin/ctr на k3s, команда уже существует в PATH по адресу /usr/bin/ctr
[INFO]  Создание скрипта killall /usr/local/bin/k3s-killall.sh
[INFO]  Создание скрипта uninstall /usr/local/bin/k3s-uninstall.sh
[INFO]  env: Создание файла окружения /etc/systemd/system/k3s.service.env
[INFO]  systemd: Создание файла службы /etc/systemd/system/k3s.service
[INFO]  systemd: Включение единицы k3s
[INFO]  systemd: Запуск k3s

Проверьте, что pod работает корректно.

$ kubectl get po -A
NAMESPACE     NAME                                      READY   STATUS      RESTARTS   AGE
kube-system   helm-install-traefik-crd-j4bwn            0/1     Completed   0          2m10s
kube-system   helm-install-traefik-sxnmw                0/1     Completed   0          2m10s
kube-system   metrics-server-86cbb8457f-47kzz           1/1     Running     0          2m10s
kube-system   local-path-provisioner-5ff76fc89d-7bzjd   1/1     Running     0          2m10s
kube-system   coredns-7448499f4d-cjph9                  1/1     Running     0          2m10s
kube-system   svclb-traefik-8q77r                       2/2     Running     0          83s
kube-system   traefik-97b44b794-gb72h                   1/1     Running     0          83s

# Основные команды для кластера
# Создадим deployment pod
$ kubectl create deployment nginx --image=nginx
$ kubectl get po
NAME                     READY   STATUS    RESTARTS   AGE
nginx-6799fc88d8-pc4wz   1/1     Running   0          101s

Настройка сетевого режима```console

Изменение режима CNI

По умолчанию K3s использует flannel в качестве CNI с VXLAN в качестве стандартного режима. Для изменения режима CNI используйте следующие команды:

--flannel-backend=vxlan (по умолчанию) Использует VXLAN режим.

--flannel-backend=ipsec Использует IPSEC режим для шифрования сетевого трафика.

--flannel-backend=host-gw Использует режим host-gw.

--flannel-backend=wireguard Использует режим WireGuard для шифрования сетевого трафика. Может потребоваться дополнительное оборудование и настройка.

$ curl -sfL http://rancher-mirror.cnrancher.com/k3s/k3s-install.sh | INSTALL_K3S_MIRROR=cn INSTALL_K3S_EXEC="--docker --flannel-backend=vxlan" sh -

$ ip a | grep flannel

31: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UNKNOWN group default
    inet 10.42.0.0/32 scope global flannel.1

# Замена CNI
# K3S поддерживает не только flannel, но и другие CNI компоненты, такие как calico/canal.
# Мы будем использовать calico в качестве сетевого компонента.

# Примечание: 10.96.0.0/16 не должно пересекаться с существующими сетями
curl -sfL http://rancher-mirror.cnrancher.com/k3s/k3s-install.sh | INSTALL_K3S_MIRROR=cn K3S_KUBECONFIG_MODE="644" INSTALL_K3S_EXEC="--flannel-backend=none --cluster-cidr=10.96.0.0/16 --disable-network-policy --disable=traefik" sh -
```# Скачайте calico.yaml
$ wget https://docs.projectcalico.org/manifests/calico.yaml
# Измените параметр CALICO_IPV4POOL_CIDR в calico.yaml
- name: CALICO_IPV4POOL_CIDR
  value: "10.96.0.0/16"

# Примените Calico
kubectl apply -f calico.yaml

# Просмотрите pods в кластере
$ kubectl get po -A
NAMESPACE     NAME                                       READY   STATUS    RESTARTS   AGE
kube-system   calico-node-6cv7v                          1/1     Running   0          3m30s
kube-system   local-path-provisioner-5ff76fc89d-sqdts    1/1     Running   0          33m
kube-system   calico-kube-controllers-74b8fbdb46-mdwjm   1/1     Running   0          3m30s
kube-system   metrics-server-86cbb8457f-5xgrs            1/1     Running   0          33m
kube-system   coredns-7448499f4d-mwtmw                   1/1     Running   0          33m

Удаление K3S

# Для удаления K3s с серверного узла
$ /usr/local/bin/k3s-uninstall.sh

# Для удаления K3s с узла агента
$ /usr/local/bin/k3s-agent-uninstall.sh

2.3 Управление краем от центра

2.3.1 Архитектура управления краем с помощью RancherВ реальных приложениях краевые среды могут содержать несколько кластеров K3S. Когда количество кластеров становится слишком большим, последующее обслуживание и управление становятся неудобными. Для решения этой проблемы мы используем Rancher в облаке для управления несколькими кластерами K3S.

2.3.2 Условия узлов

Роль узла	CPU	ОЗУ	Диск	Количество	ОС
Rancher	>2 ядра	>4 ГБ	>10 ГБ	1	CentOS 7.x
K3S	>2 ядра	>2 ГБ	>10 ГБ	n	CentOS 7.x

2.3.3 Развертывание K3S и Rancher

Развертывание K3S

Развертывание службы Rancher

$ docker run -d --restart=unless-stopped -p 1234:80 -p 2234:443 rancher/rancher:v2.3.6

2.3.4 Управление K3S

Через браузер перейдите по адресу https://{rancher_ip}:2234/

Скопируйте команду из приведенного выше изображения и выполните её на узле K3S

sudo docker run -d --privileged --restart=unless-stopped --net=host -v /etc/kubernetes:/etc/kubernetes -v /var/run:/var/run rancher/rancher-agent:v2.3.6 --server https://172.20.149.95:2234 --token ndhsgr9msksr4s6g6xqq6dl8cns42txlkxt96tsdwcl56hds568nbb --ca-checksum 5b778f411871d7caca521a0cf25cd40d8a7e28aeb1def47af829e22092c114cd --etcd --controlplane --worker

В итоге через интерфейс можно увидеть, что Rancher завершил управление кластером K3s.

Таким же образом управляем остальными кластерами K3s, что позволяет центральному узлу управлять кластерами на краях.

2.4 Использование K3S в CI/CD

K3S обладает рядом преимуществ, таких как легковесность и низкое потребление ресурсов. Воспользовавшись этими характеристиками, рассмотрим пример использования K3S в CI/CD.

2.4.1 Развертывание

Развертывание K3S```bash curl -sfL http://rancher-mirror.cnrancher.com/k3s/k3s-install.sh | INSTALL_K3S_EXEC="--docker --no-deploy=traefik --kube-apiserver-arg=feature-gates=RemoveSelfLink=false" INSTALL_K3S_MIRROR=cn sh -

--no-deploy=traefik по умолчанию включает Traefik, поэтому его не нужно развертывать

--kube-apiserver-arg=feature-gates=RemoveSelfLink=false для включения NFS-хранилища, которое требуется для K8s версии 1.20 и выше


Развертывание NFS

```bash
$ yum install nfs-utils -y
$ mkdir -p /nfs/data
$ chmod -R 777 /nfs/data

# Если требуется подключить диск, выполните:
# mkfs.xfs /dev/sdb
# mount /dev/sdb /nfs/data
# echo "/dev/sdb /nfs/data xfs defaults 0 0" >> /etc/fstab

echo "/nfs/data *(rw,no_root_squash,sync)" > /etc/exports
exportfs -r
systemctl enable nfs --now

kubectl apply -f nfs.yaml

# Файл nfs.yaml см. в приложении 'nfs.yaml'

2.4.2 Регистрация

# Запуск через Docker
docker run -d -v /opt/registry:/var/lib/registry -p 32500:5000 --restart=always --name registry registry:2

# Или если требуется развернуть в кластере K3S, можно использовать YAML-файл, см. приложение 'registry.yaml'
kubectl apply -f registry.yaml

2.4.3 Развертывание Gogs

# Аналогичная служба для хранения исходного кода, как GitLab, подробности опущены

2.4.4 Развертывание Drone

docker run --volume=/var/lib/drone:/data  --env=DRONE_GITLAB_SERVER=http://172.20.150.68:7080 --env=DRONE_LOGS_DEBUG=true --env=DRONE_GITLAB_CLIENT_ID=20f917a5c2395b40dabedd15b6acce3873770147c5fab4f4f7e188ec82cc3deb --env=DRONE_GITLAB_CLIENT_SECRET=da058f3d20ee00ab1bb14855c23610b98c682371dc215035fc35e1ace49c43d3 --env=DRONE_RPC_SECRET=4eb19c760068ea230837e2acfb98bf47 --env=DRONE_SERVER_HOST=172.20.150.68 --env=DRONE_SERVER_PROTO=http --publish=9999:80 --publish=3333:443 --restart=always --detach=true --name=drone drone/drone:2
```# Развертывание Drone runner
docker run -d -v /var/run/docker.sock:/var/run/docker.sock -e DRONE_RPC_PROTO=http -e DRONE_RPC_HOST=172.20.150.68:9999 -e DRONE_RPC_SECRET=4eb19c760068ea230837e2acfb98bf47 -e DRONE_RUNNER_CAPACITY=2 -e DRONE_RUNNER_NAME=172.20.150.103 -p 3000:3000 --restart always --name runner drone/drone-runner-docker:1
```#### 2.4.5 Настройка автоматизации .drone.yml``````console
# Аналогичен Jenkins pipeline скрипту, подробности опущены

2.4.6 Приложение YAML```markdown

nfs.yaml```yaml

Измените ${NODE_IP} в yaml на фактический IP текущей среды

apiVersion: v1 kind: ServiceAccount metadata: name: nfs-client-provisioner

замените на namespace, где развернут provisioner

namespace: default

kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: nfs-client-provisioner-runner rules:

apiGroups: [""] resources: ["persistentvolumes"] verbs: ["get", "list", "watch", "create", "delete"]
apiGroups: [""] resources: ["persistentvolumeclaims"] verbs: ["get", "list", "watch", "update"]
apiGroups: ["storage.k8s.io"] resources: ["storageclasses"] verbs: ["get", "list", "watch"]
apiGroups: [""] resources: ["events"] verbs: ["create", "update", "patch"]

kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: run-nfs-client-provisioner subjects:

kind: ServiceAccount name: nfs-client-provisioner
замените на namespace, где развернут provisioner
namespace: default roleRef: kind: ClusterRole name: nfs-client-provisioner-runner apiGroup: rbac.authorization.k8s.io

kind: Role apiVersion: rbac.authorization.k8s.io/v1 metadata: name: leader-locking-nfs-client-provisioner

замените на namespace, где развернут provisioner

namespace: default rules:

apiGroups: [""] resources: ["endpoints"] verbs: ["get", "list", "watch", "create", "update", "patch"]

kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: leader-locking-nfs-client-provisioner

замените на namespace, где развернут provisioner

namespace: default subjects:

kind: ServiceAccount name: nfs-client-provisioner
замените на namespace, где развернут provisioner
namespace: default roleRef: kind: Role name: leader-locking-nfs-client-provisioner apiGroup: rbac.authorization.k8s.io

apiVersion: apps/v1 kind: Deployment metadata: name: nfs-client-provisioner labels: app: nfs-client-provisioner namespace: default spec: replicas: 1 selector: matchLabels: app: nfs-client-provisioner strategy: type: Recreate selector: matchLabels: app: nfs-client-provisioner template: metadata: labels:

     spec:
       serviceAccountName: nfs-client-provisioner
       containers:
 ```        - name: nfs-client-provisioner
            image: quay.io/external_storage/nfs-client-provisioner:latest
            volumeMounts:
              - name: nfs-client-root
                mountPath: /persistentvolumes
            env:
              - name: PROVISIONER_NAME
                value: fuseim.pri/ifs
              - name: NFS_SERVER
                value: ${NODE_IP}
              - name: NFS_PATH
                value: /nfs/data
        volumes:
          - name: nfs-client-root
            nfs:
              server: ${NODE_IP}
              path: /nfs/data
  ---
  apiVersion: storage.k8s.io/v1
  kind: StorageClass
  metadata:
    name: nfs
  provisioner: fuseim.pri/ifs
  parameters:
    archiveOnDelete: "false"
  reclaimPolicy: Delete
  ```registry.yaml```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: registry
spec:
  replicas: 1
  selector:
    matchLabels:
      app: registry
  template:
    metadata:
      labels:
        app: registry
    spec:
      containers:
      - name: registry
        image: registry:2
        ports:
        - containerPort: 80
        volumeMounts:
        - name: registry-pvc
          mountPath: "/var/lib/registry"
      volumes:
        - name: registry-pvc
          persistentVolumeClaim:
            claimName: registry-pvc
---
apiVersion: v1
kind: Service
metadata:
  name: registry
  labels:
    app: registry
spec:
  type: NodePort
  ports:
    - name: http
      port: 5000
      targetPort: 5000
      protocol: TCP
      nodePort: 32500
  selector:
    app: registry
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: registry-pvc
spec:
  storageClassName: "nfs"
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 10Gi

2.5 Высокодоступное решение для K3S

2.5.1 Высокодоступная архитектура

Высокодоступный K3s-кластер состоит из следующих компонентов:

Узлы K3s Server : Два или более узлов K3s Server предоставляют сервис Kubernetes API и выполняют другие службы control-plane.
Внешняя база данных : В отличие от встроенной базы данных SQLite, используемой в однозначной конфигурации K3s, высокодоступный K3s требует подключения к внешней базе данных для хранения данных.

Фиксированный адрес регистрации агентских узлов

В конфигурации высокодоступного K3s сервера каждый узел должен использовать фиксированный адрес для регистрации в Kubernetes API, после регистрации агентские узлы устанавливают соединение с одним из узлов K3s Server, как показано на следующем рисунке:

2.5.2 Конфигурация высокодоступного развертывания

Предварительные условия: узлы не должны иметь одинаковых имен хоста

Роль узла	CPU	Память	Диск	Количество	ОС
server	>2 ядра	>4 ГБ	>10 ГБ	>3	centos7.x
agent	>2 ядра	>2 ГБ	>10 ГБ	>3	centos7.x

2.5.3 Развертывание внешней базы данных etcd

Развертывание внешней базы данных etcd. K3S поддерживает несколько внешних баз данных, здесь мы используем базу данных etcd. Для удобства развертывания, наша конфигурация etcd не использует TLS. Дополнительные сведения см. в документации K3S для внешней базы данных и официальной документации etcd

# На всех узлах установлен Docker, процесс одиночной установки аналогичен, поэтому подробное описание не требуется.
# Высокоуровневое развертывание etcd
# На трех узлах master выполняются следующие шаги по развертыванию etcd

wget https://github.com/etcd-io/etcd/releases/download/v3.3.15/etcd-v3.3.15-linux-amd64.tar.gz
tar -vxf etcd-v3.3.15-linux-amd64.tar.gz
cp etcd-v3.3.15-linux-amd64/etcd /usr/bin/
cp etcd-v3.3.15-linux-amd64/etcdctl /usr/bin/

# Управление etcd осуществляется с помощью systemd

vi /etc/systemd/system/etcd.service

# Введите конфигурацию etcd, сохраните и закройте. (Конфигурация etcd.service см. в приложении)
``````console
$ systemctl start etcd $ systemctl status etcd ● etcd.service - etcd
Загружено: загружено (/etc/systemd/system/etcd.service; отключено; предустановлено: отключено)
Активно: активно (запущено) с воскресенья 2021-10-03 18:19:52 CST; 10 с назад
Документация: https://github.com/etcd-io/etcd
```$ etcdctl member list member 763586516b512018 в хорошем состоянии: получен результат "в хорошем состоянии" от
http://{etcd1-ip}:2379 member 78bb25a565876d17 в хорошем состоянии: получен результат "в хорошем состоянии" от
http://{etcd2-ip}:2379 member da51b2723088b522 в хорошем состоянии: получен результат "в хорошем состоянии" от
http://{etcd3-ip}:2379

Примечание: Если вы будете переустанавливать кластер k3s, сначала остановите все службы etcd, очистите данные всех узлов etcd, а затем перезапустите etcd.

systemctl stop etcd
rm -rf /var/lib/etcd
systemctl restart etcd

2.5.4 Сервер HA

В следующих командах INSTALL_K3S_MIRROR, K3S_DATASTORE_ENDPOINT, K3S_TOKEN и т.д. могут быть использованы как переменные окружения, например: export K3S_TOKEN="k3s_token"

$ curl -sfL http://rancher-mirror.cnrancher.com/k3s/k3s-install.sh | INSTALL_K3S_MIRROR=cn K3S_DATASTORE_ENDPOINT='http://{etcd1-ip}:2379,http://{etcd2-ip}:2379,http://{etcd3-ip}:2379' K3S_TOKEN="k3s_token" INSTALL_K3S_VERSION=v1.18.6+k3s1 INSTALL_K3S_EXEC="--docker" sh -s - server
[INFO]  Создание символической ссылки /usr/local/bin/kubectl на k3s
[INFO]  Создание символической ссылки /usr/local/bin/crictl на k3s
[INFO]  Создание символической ссылки /usr/local/bin/ctr на k3s
[INFO]  Создание скрипта killall /usr/local/bin/k3s-killall.sh
[INFO]  Создание скрипта uninstall /usr/local/bin/k3s-uninstall.sh
[INFO]  env: Создание файла конфигурации /etc/systemd/system/k3s.service.env
[INFO]  systemd: Создание файла службы /etc/systemd/system/k3s.service
[INFO]  systemd: Включение службы k3s
[INFO]  systemd: Запуск k3s

2.5.5 Добавление агента

Все узлы агента должны выполнить команду master-ip, которая может быть общим VIP для нескольких мастеров или IP первого мастера.В следующих командах INSTALL_K3S_MIRROR, K3S_DATASTORE_ENDPOINT, K3S_TOKEN и другие могут быть использованы как переменные окружения, например: export K3S_TOKEN="k3s_token"

$ curl -sfL http://rancher-mirror.cnrancher.com/k3s/k3s-install.sh | INSTALL_K3S_MIRROR=cn K3S_TOKEN="k3s_token" K3S_URL=https://{master-ip}:6443 INSTALL_K3S_VERSION=v1.18.6+k3s1 INSTALL_K3S_EXEC="--docker" sh -
[INFO]  Создание символической ссылки /usr/local/bin/kubectl на k3s
[INFO]  Создание символической ссылки /usr/local/bin/crictl на k3s
[INFO]  Пропуск создания символической ссылки /usr/local/bin/ctr на k3s, команда уже существует в PATH по адресу /usr/bin/ctr
[INFO]  Создание скрипта killall /usr/local/bin/k3s-killall.sh
[INFO]  Создание скрипта uninstall /usr/local/bin/k3s-agent-uninstall.sh
[INFO]  env: Создание файла окружения /etc/systemd/system/k3s-agent.service.env
[INFO]  systemd: Создание файла службы /etc/systemd/system/k3s-agent.service
[INFO]  systemd: Включение unit k3s-agent
[INFO]  systemd: Запуск k3s-agent

$ kubectl get no
caasbastion-3   Ready    <none>                 3m20s   v1.21.4+k3s1
caasbastion-2   Ready    <none>                 2m49s   v1.21.4+k3s1
caasbastion-1   Ready    <none>                 2m27s   v1.21.4+k3s1
caasnode-1      Ready    control-plane,master   21m     v1.21.4+k3s1
caasnode-2      Ready    control-plane,master   19m     v1.21.4+k3s1
caasnode-3      Ready    control-plane,master   19m     v1.21.4+k3s1

2.5.6 Удаление K3S

# Для удаления K3s с серверного узла
$ /usr/local/bin/k3s-uninstall.sh

# Для удаления K3s с узла агента
$ /usr/local/bin/k3s-agent-uninstall.sh

# Если требуется перезапуск, необходимо очистить каталог данных etcd, по умолчанию '/var/lib/etcd'

2.5.7 Приложение

etcd.service```console

/etc/systemd/system/etcd.service

etcd-ip: IP текущего узла

etcd1-ip: IP текущего узла

etcd2-ip: IP второго узла

etcd3-ip: IP третьего узла

[Unit] Description=etcd Documentation=https://github.com/etcd-io/etcd After=network-online.target

```markdown
## 3. KubeEdge решение
```### 3.1 Основные понятия KubeEdge

Документ содержит выдержки из [официальной документации KubeEdge](https://kubeedge.io/zh/docs), для более подробной информации см. [официальную документацию KubeEdge](https://kubeedge.io/zh/docs/_index_zh/)

#### 3.1.1 Что такое KubeEdge

KubeEdge — это открытая система, расширяющая функции управления контейнеризированными приложениями до краевых узлов. Она позволяет расширить функции управления контейнеризированными приложениями и управления на краевых устройствах.

Система построена на основе Kubernetes и предоставляет основную инфраструктуру для сети и приложений, развертывая приложения как на облаке, так и на крае, а также синхронизируя метаданные. KubeEdge поддерживает протокол MQTT, что позволяет разработчикам писать пользовательский код и использовать ресурсы для коммуникации устройств в условиях ограничений.

KubeEdge состоит из двух частей: облачной и краевой.

#### 3.1.2 Преимущества KubeEdge

1. **Краевое вычисление**

    Запуск бизнес-логики на крае позволяет обрабатывать большие объемы данных локально. KubeEdge уменьшает запросы к ширине канала между краем и облаком, ускоряет время отклика и защищает конфиденциальность данных клиентов.

2. **Упрощение разработки**

    Разработчики могут писать приложения на основе HTTP или MQTT, контейнеризировать их и запускать их на крае или в облаке.3. **Нативная поддержка Kubernetes**

Используя KubeEdge, пользователи могут управлять приложениями, устройствами и мониторить состояние приложений/устройств на краевых узлах, как если бы они управляли кластером Kubernetes в облаке.

4. **Разнообразие приложений**

Пользователи могут легко развертывать сложные приложения для машинного обучения, распознавания изображений, обработки событий и других высоких уровней на крае.

```#### 3.1.3 Зависимости

В облачной части нам требуется:

- Кластер Kubernetes

На крае нам требуется:

- Среда выполнения контейнеров, которую мы поддерживаем:
  - Docker
  - Containerd
  - Crio
  - Virtlet
- MQTT-сервер (опционально)

### 3.2 Архитектура KubeEdge

#### 3.2.1 Компоненты KubeEdge

KubeEdge состоит из следующих компонентов:

**Облачная часть**

- **CloudHub**: CloudHub — это серверная часть Web Socket, отслеживающая изменения в облаке, кэширующая и отправляющая сообщения в EdgeHub.
- **EdgeController**: EdgeController — это расширенный контроллер Kubernetes, управляющий метаданными краевых узлов и Pod'ов, чтобы обеспечить передачу данных на указанный краевой узел.
- **DeviceController**: DeviceController — это расширенный контроллер Kubernetes, управляющий краевыми устройствами, чтобы обеспечить синхронизацию информации о устройствах и их состояния между облаком и краем.

**Краевая часть**
```- **EdgeHub**: EdgeHub — это клиентская часть Web Socket, взаимодействующая с облачными службами краевой вычислительной системы (например, контроллером Edge в архитектуре KubeEdge), включая синхронизацию обновлений ресурсов из облака, отчет о изменениях состояния краевых узлов и устройств и отправку их в облако.
- **Edged**: Edged — это агент, работающий на краевых узлах, для управления контейнеризированными приложениями.
- **EventBus**: EventBus — это клиент MQTT, взаимодействующий с MQTT-сервером (mosquitto), предоставляющий другим компонентам функции подписки и публикации.
- **ServiceBus**:
  ServiceBus — это клиент HTTP, работающий на крае, принимающий запросы от облачных служб и взаимодействующий с HTTP-сервером на крае, предоставляющий облачным службам возможность доступа к HTTP-серверу на крае по протоколу HTTP.
- **DeviceTwin**: DeviceTwin отвечает за хранение состояния устройств и синхронизацию его с облаком, а также предоставляет интерфейс для запросов приложениям.
- **MetaManager**: MetaManager — это обработчик сообщений, расположенный между Edged и EdgeHub, который отвечает за хранение/запрос метаданных в легковесной базе данных (SQLite).#### 3.2.2 Архитектура KubeEdge

![](images/kubeedge_arch.png)

### 3.3 Развертывание KubeEdge

**Ограничения использования**

- keadm в настоящее время поддерживает Ubuntu и CentOS OS. Поддержка RaspberryPi находится в разработке.
- Требуются права суперпользователя (или root-права) для запуска.

| Роль    | Окружение                | CPU    | Память  | Диск   | Количество | ОС        |
| ----- | ----------------- | ------ | --- | ---- | -- | --------- |
| cloud | K8S(AIO/HA)1.18.6 | >4Core | >4G | >50G | 1  | centos7.x |
| edge  | docker19.03.9     | >1Core | >1G | >10G | n  | centos7.x |

#### 3.3.1 Развертка с помощью Keadm

Keadm используется для установки облачных и краевых компонентов KubeEdge. **Он не отвечает за установку и запуск K8s**. Поэтому перед разверткой части KubeEdge Cloud необходимо предварительно настроить K8s кластер. [Процесс развертки K8s](class-01-Kubernetes-Administration.md#27-установка-k8s)

Вот как происходит развертка KubeEdge с помощью Keadm. Для удобства объяснения, мы будем называть **облачный кластер K8s "cloud"** и **краевые узлы "edge"**. Все операции на стороне cloud выполняются на узле **master** K8s кластера (этот узел должен иметь kubectl и kubeconfig).

Развертка cloud с помощью Keadm

```bash
# Скачивание Keadm на стороне cloud
yum update -y
yum install wget -y
wget https://github.com/kubeedge/kubeedge/releases/download/v1.8.0/keadm-v1.8.0-linux-amd64.tar.gz
tar -vxf keadm-v1.8.0-linux-amd64.tar.gz
cp keadm-v1.8.1-linux-amd64/keadm/keadm /usr/bin/
```# Развертка cloud
# Процесс развертки довольно прост, но из-за ограничений сетевого окружения в Китае, в большинстве случаев этот командный вызов не обеспечивает успешной развертки. Необходимо выполнить дополнительные вспомогательные действия```bash
# Создание директорий
mkdir -pv /etc/kubeedge
mkdir -pv /etc/kubeedge/crds
mkdir -pv /etc/kubeedge/crds/devices && /etc/kubeedge/crds/reliablesyncs && /etc/kubeedge/crds/router
```wget -k --no-check-certificate https://github.com/kubeedge/kubeedge/releases/download/v1.8.0/kubeedge-v1.8.0-linux-amd64.tar.gz -O /etc/kubeedge/kubeedge-v1.8.0-linux-amd64.tar.gz
wget -k --no-check-certificate https://raw.githubusercontent.com/kubeedge/kubeedge/release-1.8/build/tools/cloudcore.service -O /etc/kubeedge/cloudcore.service
wget -k --no-check-certificate https://raw.githubusercontent.com/kubeedge/kubeedge/release-1.8/build/crds/devices/devices_v1alpha2_device.yaml -O /etc/kubeedge/crds/devices/devices_v1alpha2_device.yaml
wget -k --no-check-certificate https://raw.githubusercontent.com/kubeedge/kubeedge/release-1.8/build/crds/reliablesyncs/devices_v1alpha2_devicemodel.yaml -O /etc/kubeedge/crds/devices/devices_v1alpha2_devicemodel.yaml
wget -k --no-check-certificate https://raw.githubusercontent.com/kubeedge/kubeedge/masrelease-1.8ter/build/crds/reliablesyncs/cluster_objectsync_v1alpha1.yaml -O /etc/kubeedge/crds/reliablesyncs/cluster_objectsync_v1alpha1.yaml
wget -k --no-check-certificate https://raw.githubusercontent.com/kubeedge/kubeedge/release-1.8/build/crds/reliablesyncs/objectsync_v1alpha1.yaml -O /etc/kubeedge/crds/reliablesyncs/objectsync_v1alpha1.yaml
wget -k --no-check-certificate https://raw.githubusercontent.com/kubeedge/kubeedge/release-1.8/build/crds/router/router_v1_ruleEndpoint.yaml -O /etc/kubeedge/crds/router/router_v1_ruleEndpoint.yaml
wget -k --no-check-certificate https://raw.githubusercontent.com/kubeedge/kubeedge/release-1.8/build/crds/router/router_v1_rule.yaml -O /etc/kubeedge/crds/router/router_v1_ruleEndpoint.yaml

# Развертывание cloud-конечной точки
# THE-EXPOSED-IP обычно является IP-адресом или VIP-адресом k8s master
# Обратите внимание: если во время развертывания появляется сообщение 'kubeedge-v1.8.0-linux-amd64.tar.gz in your path checksum failed and do you want to delete this file and try to download again? [y/N]:', введите n

$ keadm init --advertise-address="THE-EXPOSED-IP"
```Проверка версии Kubernetes пройдена, начало установки KubeEdge...
Ожидаемая или по умолчанию версия KubeEdge 1.8.0 уже загружена и будет проверена контрольной суммой.
kubeedge-v1.8.0-linux-amd64.tar.gz контрольная сумма:
содержимое файла checksum_kubeedge-v1.8.0-linux-amd64.tar.gz.txt:
kubeedge-v1.8.0-linux-amd64.tar.gz контрольная сумма в вашем пути не прошла и вы хотите удалить этот файл и попробовать загрузить снова?
[y/N]:
n
W1002 10:30:19.561552   65565 common.go:279] контрольная сумма не прошла, но установка продолжается.
[Run as service] файл службы уже существует в /etc/kubeedge/cloudcore.service, пропускаем загрузку
kubeedge-v1.8.0-linux-amd64/
kubeedge-v1.8.0-linux-amd64/edge/
kubeedge-v1.1.0-linux-amd64/edge/edgecore
kubeedge-v1.8.0-linux-amd64/cloud/
kubeedge-v1.8.0-linux-amd64/cloud/csidriver/
kubeedge-v1.8.0-linux-amd64/cloud/csidriver/csidriver
kubeedge-v1.8.0-linux-amd64/cloud/admission/
kubeedge-v1.8.0-linux-amd64/cloud/admission/admission
kubeedge-v1.8.0-linux-amd64/cloud/cloudcore/
kubeedge-v1.8.0-linux-amd64/cloud/cloudcore/cloudcore
kubeedge-v1.8.0-linux-amd64/version

KubeEdge cloudcore запущен, для просмотра логов посетите: /var/log/kubeedge/cloudcore.log
CloudCore запущен

# Просмотр службы cloudcore
$ ps aux | grep cloudcore
root      65819  0.6  1.3 900580 25600 pts/0    Sl   10:30   0:00 /usr/local/bin/cloudcore
root      65914  0.0  0.0 112812   972 pts/0    S+   10:30   0:00 grep --color=auto cloudcore

Использование Keadm для развертывания edge-конечной точки

# Все edge-узлы должны выполнить следующие действия

# Установка docker
yum update -y
yum install -y yum-utils
yum-config-manager --add-repo http://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo
yum makecache fast
yum install docker-ce-19.03.9 -y
mkdir -p /etc/docker
echo '{"registry-mirrors": ["http://hub-mirror.c.163.com"]}'>/etc/docker/daemon.json
systemctl enable --now docker
```# Загрузка keadm на edge-узел
yum install wget -y
wget https://github.com/kubeedge/kubeedge/releases/download/v1.8.0/keadm-v1.8.0-linux-amd64.tar.gz
tar -vxf keadm-v1.8.0-linux-amd64.tar.gz
cp keadm-v1.8.1-linux-amd64/keadm/keadm /usr/bin/

```# Развертывание краевых узлов
# THE-EXPOSED-IP обычно является IP-адресом или VIP-адресом k8s master-узла в облаке
# TOKEN обычно получается на стороне облака: keadm gettoken
# Включение краевых узлов в облако довольно просто, но ограничено сетью внутри страны, поэтому нам нужно выполнить некоторые вспомогательные действия

scp -r root@{THE-EXPOSED-IP}:/etc/kubeedge /etc/

keadm join --cloudcore-ipport={THE-EXPOSED-IP}:10000 --kubeedge-version=1.8.0 --token={TOKEN}

# Особое внимание: если во время развертывания появится сообщение 'kubeedge-v1.8.0-linux-amd64.tar.gz в вашем пути checksum failed и вы хотите удалить этот файл и попробовать скачать снова? [y/N]:', введите n
``````console
Узел уже имеет установленный и работающий Mosquitto, поэтому пропускаем шаги установки !!!
Ожидаемая или стандартная версия KubeEdge 1.8.0 уже скачана, и будет выполнено checksum для неё.
kubeedge-v1.8.0-linux-amd64.tar.gz checksum:
checksum_kubeedge-v1.8.0-linux-amd64.tar.gz.txt содержимое:
kubeedge-v1.8.0-linux-amd64.tar.gz в вашем пути checksum failed и вы хотите удалить этот файл и попробовать скачать снова?
[y/N]:
n
W1002 10:56:18.457155   74140 common.go:279] failed to checksum and will continue to install.
[Run as service] файл службы уже существует в /etc/kubeedge/edgecore.service, пропускаем загрузку
kubeedge-v1.8.0-linux-amd64/
kubeedge-v1.8.0-linux-amd64/edge/
kubeedge-v1.8.0-linux-amd64/edge/edgecore
kubeedge-v1.8.0-linux-amd64/cloud/
kubeedge-v1.8.0-linux-amd64/cloud/csidriver/
kubeedge-v1.8.0-linux-amd64/cloud/csidriver/csidriver
kubeedge-v1.8.0-linux-amd64/cloud/admission/
kubeedge-v1.8.0-linux-amd64/cloud/admission/admission
kubeedge-v1.8.0-linux-amd64/cloud/cloudcore/
kubeedge-v1.8.0-linux-amd64/cloud/cloudcore/cloudcore
kubeedge-v1.8.0-linux-amd64/version
```KubeEdge edgecore работает, для просмотра логов посетите: journalctl -u edgecore.service -b

# Подождите около минуты, вернитесь на сторону облака для проверки успешного включения краевых узлов
$ kubectl get no

NAME                    STATUS   ROLES        AGE   VERSION
localhost.localdomain   Ready    agent,edge   11h   v1.19.3-kubeedge-v1.8.0
master                  Ready    master       12h   v1.18.6

3.4 Анализ кей-кейсов KubeEdge

3.4.1 Анализ данных с использованием Apache Beam

Apache Beam — это открытая, унифицированная модель для определения параллельных потоков обработки данных в режиме реального времени и в режиме батч-обработки. Используя одно из открытых SDK Beam, можно создать программу, определяющую поток.

Основная цель анализатора заключается в получении данных в виде потока от mqtt-агента и в реальном времени применении правил к входящим данным, что приводит к созданию оповещений/действий на mqtt-агенте. Получение данных через канал и применение функций анализа осуществляется с помощью Apache Beam.

3.4.2 Почему используется Apache Beam для анализа

Существует множество фреймворков, таких как Hadoop, Spark, Flink, Google Cloud Dataflow и другие, используемых для потокового обработки данных. Однако нет единого API для связывания всех этих фреймворков и источников данных. Нам необходимо абстрагироваться от логики приложения от этих больших данных фреймворков. Фреймворк Apache Beam предоставляет такую абстракцию между вашим приложением и экосистемой больших данных.- Общая модель на основе данных-потока используется для построения абстрактных каналов, которые могут выполняться на любом времени выполнения (например, Flink/Samza и т.д.).

Та же самая кодировка канала может выполняться в облаке (например, на основе Apache Flink на Huawei Cloud Stream) и использоваться на краях с пользовательским backend, который эффективно распределяет нагрузку в кластерах края и выполняет распределенный анализ.
Apache Beam хорошо интегрируется с TensorFlow, используемым для машинного обучения, что является ключевым сценарием использования на краях.
Beam поддерживает большинство функций, необходимых для потоковой обработки и анализа данных.

3.4.3 Demo: Реальное время оповещение: чтение и фильтрация данных из MQTT, и создание оповещений

Базовая поддержка чтения/записи MQTT для обработки данных в партии в Apache Beam
Чтение данных из MQTT
Создание PC-коллекции для чтения данных и использование её как начальных данных для канала
Фильтрация данных
Если значение превышает порог, опубликовать оповещение на соответствующей теме

3.4.4 Demo: Фильтрация потоковых данных. Чтение потоковых данных из MQTT, периодическая фильтрация

Чтение потоковых данных с MQTT
Фильтрация данных в фиксированных интервалах времени

#### 3.4.5 Развертывание приложения канала

Предварительные условия

Golang (версия: 1.14+)
KubeEdge (версия: v1.5+)
Docker (версия: 18.09-ce+)

$ git clone https://github.com/kubeedge/examples && cd examples

# Загрузка образов
$ docker pull containerise/ke_apache_beam:ke_apache_analysis_v1.1
$ docker pull containerise/ke_apache_beam:ke_apache_analysis_v1.2

# Запуск deployment
$ kubectl apply -f examples/apache-beam-analysis/deployment.yaml

# Затем вы можете использовать следующую команду для проверки, работает ли приложение корректно.
$ kubectl get pods

3.4.6 Проверка данных

# Используйте [testmachine](publisher/testmachine.go) для публикации фейковых данных. Добавьте следующие пакеты для поставщика.

$ go get -u github.com/yosssi/gmq/mqtt
$ go get -u github.com/yosssi/gmq/mqtt/client

$ go build testmachine.go
$ ./testmachine

3.5 Принципы и применение CloudCore

Из предыдущего мы знаем, что KubeEdge Cloud Core состоит из трех основных модулей: CloudHub, EdgeController и DeviceController. Давайте рассмотрим каждый из этих модулей.

3.5.1 CloudHub

CloudHub — это модуль cloudcore, который служит посредником между контроллером и краем. Он поддерживает соединения через WebSocket и протокол QUIC. EdgeHub может выбрать протокол для доступа к CloudHub. Функция CloudHub заключается в обеспечении связи между краем и контроллером.Соединение с краем (через модуль EdgeHub) осуществляется через HTTP-соединение на WebSocket. Для внутренней связи он напрямую взаимодействует с контроллером. Все запросы, отправленные в CloudHub, являются объектами контекста и хранятся в канале channelQ вместе с каналом отображения объектов событий, помеченных nodeID.Основные функции CloudHub:

Получение контекста сообщений и создание ChannelQ для событий

Объекты контекста хранятся в канале channelQ. Для каждого nodeID создается канал, сообщение преобразуется в объект события, а затем объект события передается через канал.
Создание HTTP-соединения через WebSocket

TLS-сертификаты загружаются по пути, указанному в объекте контекста. HTTP-сервер запускается с конфигурацией TLS, а затем HTTP-соединение обновляется до WebSocket-соединения для получения объекта conn. Функция ServeConn обслуживает все входящие соединения.
Чтение сообщений с края

Сначала устанавливается срок действия для поддержания активности, затем читаются JSON-сообщения из соединения, устанавливаются детали маршрутизации сообщений, сообщение преобразуется в объект события для внутренней связи в облаке, и затем событие публикуется контроллеру.
Запись сообщений на крае

Сначала принимаются все объекты событий для заданного nodeID, проверяется наличие одного и того же запроса и активность узла, объект события преобразуется в структуру сообщения, устанавливается срок действия записи. Затем сообщение передается на WebSocket-соединение.
Публикация сообщений контроллеру При каждом запросе к WebSocket-соединению отправляется сообщение с отметкой времени, clientID и типом события. Если узел отключен, возникает ошибка, и событие, описывающее сбой узла, публикуется контроллеру. Обеспечение надежности сообщений CloudHub- CloudHub выступает в роли посредника между Controller и Edge-устройствами. Он отвечает за распределение вниз сообщений (в которых содержатся события ресурсов k8s, такие как обновление pod), а также за прием и отправку сообщений от Edge-устройств к Controller. Сообщения, отправляемые вниз, укреплены на уровне приложения для повышения надежности передачи, чтобы противостоять слабым сетям между облаком и краем.

Подключение к краю (через модуль EdgeHub) осуществляется через опциональное соединение websocket/quic. Для внутренней коммуникации в Cloudcore CloudHub напрямую взаимодействует с Controller. Все запросы, отправленные Controller к CloudHub, хранятся в канале channelq вместе с каналом, используемым для хранения объектов событий этого краевого узла.
Если сообщение является типом message, это означает, что EdgeController и devicecontroller должны синхронизировать сообщения, отправляемые краевому узлу. В этом случае требуется взаимодействие CloudHub и EdgeHub для передачи сообщений. Однако, учитывая нестабильность сети между облаком и краем, что может привести к частому отключению краевых узлов, перезапуск или отключение cloudcore или edgecore на некоторое время может привести к потере сообщений, отправленных краевым узлам. Без надежной передачи сообщений эти сообщения не будут доставлены. Если новые события не были успешно отправлены краевому узлу, это приведет к несогласованности между облаком и краем.Поэтому требуется надежная система передачи сообщений, которая должна покрывать следующие случаи:
1. Если cloudcore перезапускается или отключается на некоторое время, при каждом перезапуске cloudcore последнее событие должно быть отправлено краевому узлу (если есть какие-либо обновления для отправки).
2. Если краевой узел перезапускается или отключается на некоторое время, при каждом перезапуске этого узла cloudcore должен отправлять последнее событие, чтобы убедиться, что узел находится в актуальном состоянии.Надежная система передачи сообщений CloudHub: три типа механизмов передачи сообщений

Максимум один раз At-Most-Once
Точно один раз Exactly-Once
Минимум один раз At-Least-Once

Первый метод "Максимум один раз" является ненадежным, второй метод "Точно один раз" имеет высокую стоимость, хотя он обеспечивает надежную передачу сообщений без потери или повторения сообщений, но его производительность значительно ниже по сравнению с третьим методом.

Так как KubeEdge следует принципу конечной согласованности Kubernetes, то повторное получение краевым узлом одного и того же сообщения не является проблемой, если это последнее сообщение. Поэтому KubeEdge использует метод "Минимум один раз".

Ниже приведен конкретный процесс передачи сообщений от облака к краю.1. KubeEdge использует K8s CRD для хранения последней версии resourceVersion ресурсов, успешно отправленных на Edge. При перезапуске cloudcore или при обычном запуске он проверяет resourceVersion, чтобы избежать отправки старых сообщений. 2. EdgeController и devicecontroller отправляют сообщения на Cloudhub, MessageDispatcher направляет сообщения на соответствующую NodeMessageQueue в зависимости от имени узла в сообщении. 3. CloudHub последовательно отправляет данные из NodeMessageQueue на соответствующий краевой узел [5] и хранит идентификатор сообщения в канале ACK [4]. При получении ACK-сообщения от краевого узла канал ACK активирует сохранение resourceVersion сообщения в CRD на K8s [11] и отправку следующего сообщения. 4. Когда Edgecore получает сообщение, он сначала сохраняет его в локальное хранилище данных, а затем возвращает ACK-сообщение в облако. Если cloudhub не получит ACK-сообщение в течение этого интервала, он продолжит повторную отправку сообщения 5 раз. Если все 5 попыток не удастся, cloudhub отбросит это событие. 5. SyncController будет обрабатывать эти неудачные события. Даже если краевой узел получил сообщение, возвращенное ACK-сообщение может быть потеряно в процессе передачи. В этом случае cloudhub снова отправит сообщение, и краевой узел сможет обработать повторное сообщение.#### 3.5.2 EdgeController

Мы знаем, что EdgeController — это расширенный Kubernetes-контроллер, управляющий метаданными краевых узлов и Pod, чтобы обеспечить передачу данных на указанный краевой узел.

Структура EdgeController

upstream обрабатывает данные вверх по цепочке (аналогично отчету kubelet о своем состоянии в native k8s, здесь основное отчет о состоянии краевого узла node и pod); downstream обрабатывает данные вниз по цепочке. Облачно-краевое взаимодействие использует обертку сообщений поверх websocket, и не происходит полной синхронизации данных, а только синхронизирует данные, наиболее важные для данного узла. После перезапуска краевого узла из-за сбоя он не будет выполнять re-list, так как краевой узел использует устойчивое хранение, восстанавливаясь из локального хранилища. Как поддерживать актуальность локальных данных? Это происходит за счет постоянной синхронизации изменений данных с облака на краевой узел через downstream.

При запуске системы EdgeController внутри CloudCore будет наблюдать за многими ресурсами. Для Pod он будет наблюдать за всеми Pod, но внутри будет применять фильтрацию, но фильтрация не будет отражаться в list-watch, а будет обрабатываться только при внутреннем раздаче.

3.5.3 DeviceControllerDeviceController является частью облачных компонентов KubeEdge и отвечает за управление устройствами. Это типичная реализация оператора, которая включает пользовательский API-объект и соответствующий пользовательский контроллер для управления жизненным циклом этого объекта.KubeEdge использует механизм CRD (Custom Resource Definitions), предоставляемый Kubernetes, для абстракции реальных физических устройств. Это достигается путем определения пользовательского ресурса (Custom Resource) под названием Device, который описывает метаданные и состояние устройства. DeviceController, как следует из его названия, является контроллером этого ресурса и отвечает за синхронизацию информации о устройствах между облаком и краем. В реализации DeviceController используются два независимых горутина (goroutines): downstream и upstream. Downstream слушает Kubernetes API Server для синхронизации состояния устройств с облаком на крае, а upstream подписывается на сообщения от края и синхронизирует их с API Server.

В KubeEdge DeviceController использует следующие концепции для абстракции устройств:

DeviceModel: описывает атрибуты (properties) устройства и определяет методы доступа к этим атрибутам (property visitor). DeviceModel можно рассматривать как шаблон для группы устройств. Подробное описание DeviceModel см. здесь.
DeviceInstance: представляет собой конкретное устройство. DeviceInstance создается с использованием DeviceModel. Device Spec описывает желаемое состояние устройства, а Device Status — текущее состояние устройства. Подробное описание DeviceInstance см. здесь.

### 3.6 Принцип и применение EdgeCore

Из предыдущего описания мы знаем, что KubeEdge Edge Core состоит из следующих модулей: EdgeCore включает в себя Edged, EdgeHub, MetaManager, DeviceTwin, EventBus, ServiceBus. Давайте рассмотрим каждый из этих модулей подробнее.

3.6.1 Edged

Edged — это модуль управления жизненным циклом узла на краю сети. Он помогает пользователям развертывать контейнеризированные рабочие нагрузки или приложения на краевых узлах. Эти рабочие нагрузки могут выполнять любые действия, от простого мониторинга данных до анализа или ML-выводов. Используя командную строку kubectl, пользователи могут отправлять команды для запуска рабочих нагрузок.

Текущая поддержка управления контейнерами и образами включает Docker-контейнерный runtime. В будущем планируется добавить поддержку других runtimes, таких как containerd. Множество модулей работает вместе для обеспечения функциональности edged.

Управление pod: используется для добавления, удаления и изменения pod. Также использует pod status manager и pleg для отслеживания состояния pod. Основные функции включают:
- Получение и обработка сообщений о добавлении, удалении и изменении pod от MetaManager.
- Обработка отдельных очередей для добавления и удаления контейнеров.
- Обработка рабочих процессов для проверки очередей рабочих процессов для выполнения операций pod.
- Сохранение отдельных кэшей для config map и secrets.
- Регулярная очистка изолированных pod.- Генератор событий жизненного цикла pod
CRI краевая обработка
Управление secret
Управление probe
Управление ConfigMap
Управление сборкой контейнеров
Управление сборкой образов
Управление статусом
Управление томами
MetaClient

3.6.2 EdgeHub

Edge Hub отвечает за взаимодействие с компонентом CloudHub, существующим в облаке. Он может использовать соединения WebSocket или протокол QUIC для подключения к CloudHub. Edge Hub поддерживает синхронное обновление ресурсов в облаке, отчет о изменениях состояния узла и устройств на крае, и т.д. Он служит связующим звеном между краем и облаком. Edge Hub перенаправляет сообщения, полученные от облака, к соответствующим модулям на крае, и наоборот.

Основные функции, выполняемые EdgeHub, включают:

Поддержание активности
Публикация информации о клиенте
Перенаправление в облако
Перенаправление на крае

В EdgeHub есть два типа клиентов: httpclient и websocket/quic клиент. Первый используется для запроса сертификатов, необходимых для коммуникации с EdgeCore и CloudCore, а второй отвечает за повседневную коммуникацию с CloudCore (распределение ресурсов, отправка состояния и т. д.). Когда EdgeHub запускается, он сначала запрашивает сертификат у CloudCore (если локальные сертификаты правильно настроены, то используются локальные сертификаты). Затем инициализирует websocket/quic клиент для связи с CloudCore, и после успешного подключения передаёт информацию о подключении другим компонентам (MetaGroup, TwinGroup, BusGroup). Затем запускаются три горутины для постоянного распределения сообщений с облака на края и с краёв на облако (без какого-либо упаковывания или изменения), а также для отчёта о состоянии здоровья. В случае возникновения ошибок при передаче сообщений между облаком и краями, на краях инициируется перезапуск соответствующего websocket/quic клиента для восстановления подключения к облаку.

3.6.3 MetaManagerMetaManager — это обработчик сообщений между edged и edgehub. Он также отвечает за хранение метаданных в легковесной базе данных (SQLite) или за их извлечение.

Metamanager получает различные типы сообщений в соответствии со следующим списком операций:

Insert
Update
Delete
Query
Response
NodeConnection
MetaSync

3.6.4 DeviceTwin

DeviceTwin модуль отвечает за хранение состояния устройств, обработку свойств устройств, выполнение операций DeviceTwin, создание членства между устройствами и узлами на краю, синхронизацию состояния устройств с облаком и синхронизацию информации DeviceTwin между краем и облаком. Он также предоставляет интерфейс для запросов приложениям.

DeviceTwin состоит из четырёх подмодулей для выполнения обязанностей модуля DeviceTwin:

Membership Module
Twin Module Bölüm
Communication Module
Device Module

В плане хранения данных устройства хранятся в локальной базе данных SQLite, включающей три таблицы:

device
deviceAttr
deviceTwin

Обработка сообщений, отправленных в модуль twin от других модулей, а затем вызов dtc.distributeMsg для обработки сообщений. В логике обработки сообщений сообщения делятся на четыре категории и отправляются на выполнение соответствующих действий (каждая категория включает несколько действий):

membership
device
communication
twin

3.6.5 Eventbus

Eventbus служит интерфейсом для отправки/получения сообщений о mqtt-темах, он поддерживает три режима:- внутреннийMqttMode

внешнийMqttMode
обаMqttMode

3.6.6 ServiceBus

ServiceBus — это HTTP-клиент, работающий на краю, который принимает запросы от облачных сервисов, взаимодействует с HTTP-сервером, работающим на краю, и предоставляет возможность облачным сервисам обращаться к HTTP-серверу на краю через протокол HTTP.

ServiceBus обычно запускает goroutine для приема сообщений от beehive, затем, на основе параметров в сообщении, использует HTTP-клиент для отправки сообщений через REST-API на локальный адрес 127.0.0.1 в целевое приложение. Это эквивалентно клиенту, а приложение — HTTP-серверу Rest-API, все операции и состояние устройств требуют вызова соответствующих интерфейсов для их выполнения и получения.

4. Решение EdgeX Foundry

4.1 Введение в EdgeX Foundry

Документ содержит отдельные фрагменты, взятые с официального сайта EdgeX Foundry, для получения более подробной информации обратитесь к открытому проекту EdgeX Foundry. EdgeX Foundry — это открытая платформа для промежуточного программного обеспечения IoT на краю, созданная под эгидой LF Edge. Она представляет собой гибкий и масштабируемый открытый программный фреймворк, который способствует взаимодействию между устройствами IoT на краю и приложениями. Эта платформа, поддерживаемая экосистемой, является предпочтительной открытой платформой для развертывания и использования на краю.#### 4.1.1 Особенности EdgeX Foundry

EdgeX Foundry должна быть платформо-независимой
- Хардварь (x86, ARM)
- Операционная система (Linux, Windows, MacOS, ...)
- Поддержка распределённой (через архитектуру микросервисов, поддерживающую развертывание на краевых узлах, шлюзах, узлах тумана, облачных платформах и т.д.)
- Развертывание/оркестрация (Docker, Snaps, K8s, roll-your-own...)
- Протоколы (северные или южные протоколы) Примечание: EdgeX Foundry определяет концепцию южного и северного, где южный — это устройства, источник данных, а северный — это центр использования данных, собирающий данные из южного.
EdgeX Foundry должна быть очень гибкой

Любая часть платформы может быть обновлена или заменена другими микросервисами или программными компонентами. Все службы могут быть масштабированы в зависимости от возможностей устройств и сценариев использования.3. EdgeX Foundry должна предлагать "ссылочные реализации" услуг, но поощрять оптимальные решения
EdgeX Foundry должна предлагать возможности хранения и пересылки
- Поддержка отключенных/удалённых краевых систем
- Для обработки прерывистых соединений
EdgeX Foundry должна поддерживать и способствовать перемещению "умных" функций на краю, чтобы решить
- Проблемы задержек
- Проблемы пропускной способности и хранения
- Проблемы удалённого управления
EdgeX Foundry должна поддерживать развертывание устройств/датчиков棕色和绿色 на местах
EdgeX Foundry должна быть безопасной и удобной для управления

Версия с исправлениями: 6. EdgeX Foundry должна поддерживать развертывание устройств/датчиков棕色和绿色 на местах

Исправленная версия: 6. EdgeX Foundry должна поддерживать развертывание устройств/датчиков棕色 и зелёных на местах#### 4.1.2 Архитектурное описание

Архитектура EdgeXFoundry представлена на рисунке выше (текущая версия hanoi, и версии fuji уже изменились). Она состоит из серии микросервисов, включающих 4 логических слоя и 2 сервиса, проходящих через всю платформу: безопасность и управление устройствами и системами.

Уровень сервисов устройств (Device Services): Наиболее нижний логический уровень, представляющий собой набор конкретных микросервисов, которые обеспечивают прямое взаимодействие с физическими устройствами. Каждый микросервис устройств может управлять несколькими физическими устройствами, поддерживающими соответствующие интерфейсы.
Уровень ядра сервисов (Core Services): Над уровнем сервисов устройств находится уровень ядра сервисов, который включает в себя core-data (ядро данных), core-command (ядро команд), core-metadata (ядро метаданных) и registry&config (регистрация и конфигурация). Внутри registry&config используется сервис обнаружения и управления конфигурациями Consul от Google, написанный на языке программирования Go. Поэтому в проекте нет исходного кода для микросервисов registry&config.
Уровень поддерживающих сервисов (Supporting Services): Над уровнем ядра сервисов находится уровень поддерживающих сервисов, который предоставляет общий уровень сервисов, включающий правилный движок, расписание, оповещения и уведомления, расширяемые сервисы и т. д.- Уровень сервисов приложений (Application Services): Включает в себя SDK-интерфейсы для внешних систем, настраиваемые сервисы приложений и расширяемые сервисы приложений. #### 4.1.3 Центральный слой сервисовЦентральные сервисы предоставляют посредничество между двумя сторонами EdgeX — северной и южной. Как следует из их названия, они являются "ядром" функций EdgeX. Центральные сервисы содержат большую часть встроенных знаний о том, какие устройства подключены, какие данные проходят через систему и как настроить EdgeX.

Южная сторона подключена к множеству физических устройств, один или несколько устройств с одинаковым интерфейсом подключаются к системе через один и тот же сервис устройств (device service). Северная сторона направлена на конечное место хранения данных, которое может быть облачным сервисом на расстоянии или локальным сервисом обработки данных.

4.1.4 Слой поддерживающих сервисов

Поддерживающие сервисы включают серию микросервисов, включая анализ на краю (также известный как локальный анализ). Микросервисы поддерживающего слоя выполняют обязанности обычных программных приложений, такие как логирование, планирование и очистка данных (в EdgeX также известная как "очистка").

Поддерживающие сервисы обычно требуют некоторых центральных сервисов для своей работы. В любом случае, поддерживающие сервисы могут рассматриваться как необязательные — то есть, в зависимости от требований к использованию и ресурсов системы, они могут быть исключены из развертывания EdgeX.Поддерживающие сервисы включают:- Правило движка: ссылаясь на сервис анализа на краю, он выполняет условные операторы if-then на основе данных сенсоров, собранных в экземпляре EdgeX. Этот сервис может быть заменен или усилен специфическими для использования аналитическими функциями.

Планирование: внутренний "часы" EdgeX, которые могут запускать операции в любом сервисе EdgeX. В определенное время, указанное в конфигурации, сервис может запускать операции, вызывая API URL любого сервиса EdgeX через REST. Например, сервис планирования регулярно вызывает API данных ядра для очистки "старых событий", успешно экспортированных из EdgeX.
Логирование: центральный инструмент логирования для всех сервисов EdgeX. Сервисы отправляют записи логов через REST API в инструмент логирования, где содержимое логов может быть сохранено в базе данных или файле логов. Примечание: этот сервис был отключен и будет удален после выпуска версии Женева. Сервис все еще может использовать стандартный вывод или записывать в файл. Большинство операционных систем и инструментов логирования предлагают лучшую агрегацию логов, чем EdgeX через сервис логирования.
Предупреждения и уведомления: центральный сервис для отправки предупреждений или уведомлений.Эти уведомления отправляются в другую систему или к лицам, которые наблюдают за экземпляром EdgeX (внутренняя коммуникация сервисов обычно обрабатывается напрямую). #### 4. 1. 5 Уровень прикладных сервисовПрикладные сервисы представляют собой методы извлечения, обработки/преобразования и отправки данных сенсоров на выбранные конечные точки или процессы из EdgeX. Сегодня EdgeX предоставляет примеры прикладных сервисов, которые могут отправлять данные на многие основные облачные провайдеры (Amazon IoT Hub, Google IoT Core, Azure IoT Hub, IBM Watson IoT…), MQTT(s) протоколы и HTTP(s) REST конечные точки.

Прикладные сервисы основаны на концепции "функциональной конвейерной ленты". Функциональная конвейерная лента представляет собой набор функций, обрабатывающих сообщения в определенном порядке (в данном случае сообщения EdgeX событий).

Первая функция в конвейерной ленте является триггером. Триггер запускает выполнение функциональной конвейерной ленты. Например, триггер может быть аналогичен сообщению в очереди сообщений. Затем каждая подфункция действует на сообщение. Обычные функции включают фильтрацию, преобразование (например, в XML или JSON), сжатие и шифрование. Когда сообщение проходит через все компоненты функций и устанавливается приемник, функциональная конвейерная лента завершается. Пример завершенного прикладного сервиса — это отправка сгенерированного сообщения по протоколу MQTT для отправки в Azure или AWS.

4.1.6 Уровень сервисов устройствУровень сервисов устройств соединяет "вещи" (сенсоры и устройства) с EdgeX.

Сервисы устройств являются соединителями на краю сети, взаимодействующими с "вещами", включая, но не ограничиваясь, системами оповещения, системами отопления и кондиционирования в жилых и офисных зданиях, освещением, машинами, дронами, автоматизированными системами транспорта, включая некоторые железнодорожные системы; в будущем, это может включать беспилотные автомобили и грузовики, системы управления дорожным движением, полностью автоматизированные быстродействующие заведения, полностью автоматизированные самообслуживания продуктовые магазины, устройства для получения медицинских показателей с пациентов и т.д.

Сервисы устройств могут обслуживать одно или несколько "вещей" или устройств (сенсоры, исполнительные устройства и т.д.). Устройства, управляемые сервисами устройств, могут не быть простыми физическими устройствами. Это может быть другой шлюз (и все устройства этого шлюза), менеджер устройств, агрегатор устройств или набор устройств.Сервисы устройств взаимодействуют с устройствами, сенсорами, исполнительными устройствами и другими объектами IoT посредством локальных протоколов каждого объекта. Сервисы устройств преобразуют данные, созданные и переданные объектами IoT, в универсальные структуры данных EdgeX Foundry и отправляют преобразованные данные на уровень сервисов ядра и другие микросервисы в других уровнях EdgeX Foundry.EdgeX поставляется с множеством сервисов устройств, которые поддерживают многие общие протоколы IoT, такие как Modbus, BACnet, BLE и т.д.

4.1.7 Уровень системных сервисов

Базовые сервисы безопасности EdgeX Foundry обеспечивают защиту устройств, датчиков и других объектов Интернета вещей, управляемых EdgeX Foundry. Учитывая, что EdgeX является поставщиком "нейтральной открытой платформы программного обеспечения для краудовых сетей", безопасные характеристики EdgeX также основаны на открытых интерфейсах и модулях, которые можно подключать и отключать.

Существуют два основных компонента безопасности:

Безопасное хранилище, которое хранит зашифрованные данные для EdgeX. Примеры зашифрованных данных EdgeX включают пароли доступа к базе данных, используемые другими службами для подключения к системе управления облаком.
API-шлюз, который работает как обратный прокси для доступа к ограниченному REST-ресурсу EdgeX и выполняет работу по контролю доступа. Системный управляющий сервис предоставляет центральную точку доступа для внешних систем управления, чтобы запускать/останавливать/перезапускать службы EdgeX, получать состояние/здоровье службы или метрики службы (например, использование памяти), чтобы мониторить службы EdgeX.

Программные наборы разработки (SDK)EdgeX предлагает два типа SDK для помощи в создании "северо-южных" служб — особенно для создания служб приложений и устройств. Южные и северные службы SDK упрощают подключение новых "вещей" или новых систем управления облаком/предприятий, предоставляя разработчикам код компонентов, отвечающих за базовые операции службы. Таким образом, разработчики могут сосредоточиться на деталях подключения к северным или южным объектам, не беспокоясь о всех исходных коммуникациях микрослужбы.

Сейчас EdgeX предлагает следующие SDK для разработки на языках программирования:

Golang SDK для служб устройств
C SDK для служб устройств

4.2 Развертывание EdgeX Foundry

4.2.1 Установка Docker

4.2.2 Развертывание Docker

Установка Docker

4.2.3 Python3

# Установка зависимостей
yum install -y openssl-devel openssl-static zlib-devel lzma tk-devel xz-devel bzip2-devel ncurses-devel gdbm-devel readline-devel sqlite-devel gcc libffi-devel python-devel

# Установка Python3
wget https://www.python.org/ftp/python/3.7.0/Python-3.7.0.tgz
tar -xvf Python-3.7.0.tgz
mv Python-3.7.0 /usr/local
cd /usr/local/Python-3.7.0/
./configure
make
make install
ln -s /usr/local/Python-3.7.0/python /usr/bin/python3

pip3 install --upgrade pip

4.2.4 Установка EdgeX Foundry

# Установка docker-compose
pip3 install docker-compose

# Скачивание yaml EdgeX Foundry
cd
git clone https://github.com/edgexfoundry/developer-scripts
cp developer-scripts/releases/hanoi/docker-compose-hanoi.yml ./docker-compose.yml
sed -i "s/127.0.0.1/0.0.0.0/g" ./docker-compose.yml
docker-compose up -d
``````console
# Просмотр контейнеров
$ docker-compose ps

Name Command State Ports

edgex-app-service-configurable-rules /app-service-configurable . . . Запущено 48095/tcp, 0.0.0.0:48100->48100/tcp edgex-core-command /core-command -cp=consul. h . . . Запущено 0.0.0.0:48082->48082/tcp edgex-core-consul edgex-consul-entrypoint. sh . . . Запущено 8300/tcp, 8301/tcp, 8301/udp, 8302/tcp, 8302/udp, 8400/tcp, 0.0.0.0:8500->8500/tcp, 8600/tcp, 8600/udp edgex-core-data /core-data -cp=consul. http . . . Запущено 0.0.0.0:48080->48080/tcp, 0.0.0.0:5563->5563/tcp edgex-core-metadata /core-metadata -cp=consul. . . . Запущено 0.0.0.0:48081->48081/tcp edgex-device-rest /device-rest-go --cp=consu . . . Запущено 0.0.0.0:49986->49986/tcp edgex-device-virtual /device-virtual --cp=consu . . . Запущено 0.0.0.0:49990->49990/tcp edgex-kuiper /usr/bin/docker-entrypoint . . . Запущено 0.0.0.0:20498->20498/tcp, 0.0.0.0:48075->48075/tcp, 9081/tcp edgex-proxy /bin/sh -c until /consul/s . . . Завершено edgex-redis docker-entrypoint. sh redis . . . Запущено 0.0.0.0:6379->6379/tcp edgex-secrets-setup entrypoint. sh generate Запущено edgex-security-bootstrap-database /entrypoint. sh Запущено edgex-support-notifications /support-notifications -cp . . . Запущено 0.0.0.0:48060->48060/tcp edgex-support-scheduler /support-scheduler -cp=con . . . Запущено 0.0.0.0:48085->48085/tcp edgex-sys-mgmt-agent /sys-mgmt-agent -cp=consul . . . Запущено 0.0.0.0:0:48090->48090/tcp edgex-vault /vault/init/start_vault.sh Запущено 0.0.0.0:8200->8200/tcp edgex-vault-worker entrypoint.sh Запущено kong /docker-entrypoint.sh /bin/. . . Запущено 0.0.0.0:8000->8000/tcp, 0.0.0.0:8001->8001/tcp, 0.0.0.0:8443->8443/tcp, 0.0.0.0:8444->8444/tcp kong-db docker-entrypoint.sh postgres Запущено 0.0.0.0:5432->5432/tcp kong-migrations /docker-entrypoint.sh /bin/. . . Завершено с кодом 0 #### 4.2.5 Запуск проверки и тестированияtxt

доступ к веб-странице

http://{адрес узла}:48080/api/v1/ping http://{адрес узла}:8500


![web](images/dashbord.png)

#### 4.2.6 Остановка и удаление

```bash
# в директории docker-compose.yml

# остановка
docker-compose stop

# удаление
docker-compose down

# просмотр логов
docker-compose logs -f [имя контейнера]

4.3 Пример использования EdgeX Foundry

Умный стадион / Открытая система управления недвижимостью

Пользовательский интерфейс: U3D/UE4/веб/App
Бизнес-логика: управление недвижимостью/офис
Центральная система: IoT-платформа (EdgeX), пользователи, права доступа
Слой адаптации IoT
IoT: внешние IoT-интерфейсы
Сетевой слой: BA/Bodbus/Zigbee/NBIoT/HTTP
Слой сенсоров: устройства (датчики)

5 Краевое вычисление

5.1 Технологическая архитектура краевого вычисления

ETSI MEC + краевое облако
Телекоммуникационная PaaS
Перенос UPF-узлов в краевую сеть

5.1.1 Основная архитектура MEC - ETSI

Форма краевого вычисления: MEC + краевое облако.

Краевое облако представляет собой небольшую облачную платформу, построенную на крае сети.
MEC представляет собой систему управления приложениями для телекоммуникационных операторов, развившуюся из NFV.


1. Отказ от "тупых каналов" и создание MEC-платформы, объединяющей OT, IT и CT. По оценке Chetan Sharma, MEC может привести к росту дохода более чем на 4 триллиона долларов к 2030 году, из которых более 75% приходится на доходы от приложений, а доходы от каналов связи остаются незначительными.

    ![](images/mec-edge-internet-economy.png)

1. Объединение облака и сети, а также координация облака и края являются основным преимуществом телекоммуникационных операторов. Создание PaaS для телекоммуникационных приложений. Исследование Analysys Mason среди глобальных операторов показало, что 63% операторов хотят непосредственно участвовать в прибыльном рынке MEC, а 70% операторов хотят предлагать PaaS.

    ![](images/mec-cloud-network-edge.png)

#### 5.1.3 Соответствие стандартам 3GPP для телекоммуникационной PaaS![](images/mec-3gpp-5g.png)1. Введение архитектуры SBA (Service-Based Architecture) превратило функции сетевых элементов в сервисы, обеспечив легковесное и низкозависимое взаимодействие между сервисами. Это сделало 5G-сеть гибкой и способной к быстрому развертыванию по требованию.
2. Распределенная архитектура eSBA (enhanced Service-Based Architecture) разделяет бизнес-функции и фреймворк, делегируя функции обнаружения, регистрации и управления маршрутизацией в качестве базовых функций фреймворка. Эти функции предоставляются бизнес-сервисам через агента фреймворка.
3. 5G-облачные технологии предоставляют телекоммуникационную инфраструктуру, позволяя быстро разрабатывать и проектировать сетевые функции и услуги с помощью платформы PaaS (Platform as a Service), а также гибко развертывать сети.![](images/mec-xgvela.png)#### 5.1.4 PaaS платформа

![](images/openshift-arch.png)

- Уровень инфраструктуры: предоставляет вычислительные, сетевые, хранилищные и безопасностные ресурсы, поддерживает развертывание OpenShift на физических, виртуальных машинах, частных и публичных облаках.
- Уровень контейнерного движка: использует контейнерный движок Docker, а в более новых версиях применяется CRI-O, предложенный RedHat.
- Уровень контейнерной оркестрации: использует Kubernetes для управления и оркестрации контейнеров.
- Уровень PaaS-сервисов: OpenShift предоставляет богатый набор языков программирования, фреймворков, баз данных, промежуточного программного обеспечения и поддержки приложений на уровне PaaS. Поддерживает автоматизацию сборки, развертывания, управления жизненным циклом приложений (CI/CD), каталоги услуг, встроенные репозитории образов и т. д. Конечная цель — создание PaaS-платформы, ориентированной на приложения, которая ускоряет разработку, развертывание и эксплуатацию приложений. Эти услуги недоступны в Kubernetes, используемом как CaaS.
- Уровень интерфейсов и инструментов: важной особенностью облачных платформ является поддержка самоуслуг пользователей, что снижает затраты на эксплуатацию и повышает эффективность обслуживания. OpenShift предоставляет корпоративный веб-интерфейс и набор инструментов для эксплуатации.![](images/openshift-sriov.png)

![](images/openshift-multus.png)

![](images/openshift-istio.png)

![](images/openshift-serverless.png)

### 5.2 Построение архитектуры ubiquitous computing на основе MEC

#### 5.2.1 Распределенная операционная система для облачных систем

![](images/mec-cloud-os.png)

- **Предоставление легковесных ресурсов для погружения или удаленного управления на краевых узлах**: для сценариев, где краевые ресурсы ограничены, требуется предоставление легковесных ресурсов, которые также могут поддерживать удаленное управление.
- **Управление полным жизненным циклом краевых приложений и услуг**: автоматическое подключение/отключение краевых приложений, автоматическое создание/обновление правил пользовательского интерфейса, управление центром регистрации краевых услуг.
- **Облачное управление**: облачное управление, реализованное с использованием MEC для построения операционной системы.
- **Архитектура, ориентированная на микросервисы, для дифференцированного управления**: создание многосубъектных, многосценарных, дифференцированных возможностей управления по запросу.
- **Поддержка различных типов VIM для удовлетворения различных сценариев ресурсных пулов**: помимо традиционных IaaS, CaaS, PaaS платформ, также поддерживаются VIM-типы KubeEdge, K3S и другие гетерогенные системы управления.

#### 5.2.2 Распределенная облачная система с использованием KubeEdge в качестве основы MEC![](images/kubeEdge-in-mec.png)

#### 5.2.3 Облачное управление на основе MEC

![](images/mec-cloud-edge.png)

- **Основа облачно-краевых взаимодействий** заключается в использовании преимуществ центрального облака и краевых облаков, чтобы достичь пиковых значений соотношения вычислительных, сетевых затрат и дохода от бизнеса.
- Идеальное состояние заключается в интеграции облачной и сетевой инфраструктуры, что позволяет центральному облаку и краевому облаку предоставлять вычислительные и хранилищные услуги, образуя единое облачно-краевое решение, то есть:
  - Позволяет вычислениям и данным свободно перемещаться между облачной и краевой средами.
  - Виртуальные машины облачных пользователей могут быть перенаправлены на краевую сторону.
  - Обеспечивает единое управление вычислительными ресурсами между облачной и краевой средами на основе бизнес-требований и вычислительной нагрузки.

#### 5.2.4 UPGW в MEC

![](images/mec-upgw.png)

#### 5.2.5 Облачный адаптер в MEC

![](images/mec-cloud-adapter.png)

![](images/mec-cloud-adapter-baidu.png)

## 6. Практика в корпоративной среде

### 6.1 Общее управление центральным и краевым облаками

![](images/caas-kaas-paas.png)

#### 6.1.1 Высокоуровневое решение для обеспечения доступности сервиса Harbor

![](images/harbor-arch.png)

#### 6.1.2 Решение для единого управления кластерами в нескольких регионах

![](images/multi-region-caas.png)- Решение для управления жизненным циклом K8S / K3S
- Решение для автоматической регистрации узлов

### 6.2 Корпоративное решение для облачно-краевой интеграции

#### 6.2.1 KubeEdge

Облачно-краевое надежное взаимодействие:

- Двухсторонний многоканальный канал передачи сообщений, поддерживающий работу краевых узлов в частных сетях.
- WebSocket + упаковка сообщений или QUIC, значительно снижающие нагрузку на сеть, позволяющие работать при высоких задержках.
- Проверка сообщений между облачной и краевой сторонами, предотвращающая потерю данных при нестабильной сети.

Краевое автономное управление:

- Сохранение метаданных узлов, обеспечивающее автономное управление на уровне узлов.
- Восстановление узлов без использования List-watch, снижающее нагрузку на сеть и ускоряющее процесс готовности.

Краевое минималистичное решение:

- Переработка функциональных модулей Kubelet, обеспечивающая минимальное потребление ресурсов (около 70 МБ памяти).
- Поддержка интеграции CRI с Containerd и CRI-O, оптимизирующая использование ресурсов Runtime.

Управление краевыми устройствами:

- Управление краевыми устройствами через Kubernetes API с облачной стороны.Краевая IoT-шлюз представляет собой переработанную версию встроенной шлюзовой системы с использованием облачных технологий, предоставляющую возможности преобразования протоколов/интерфейсов, краевых вычислений и управления ресурсами краевых узлов, а также управления приложениями и бизнес-компоновкой на стороне облачной инфраструктуры.![](images/kubeedge-iot-gw.png)

#### 6.2.2 OpenYurt

![](images/openyurt-arch.png)

- Полная совместимость с экосистемой Kubernetes: отсутствие вторжений в native Kubernetes обеспечивает полную совместимость с экосистемой Kubernetes. OpenYurt кластер может следовать темпу обновлений версий Kubernetes, что позволяет легко внедрять основные технологии облака в OpenYurt;
- Поддержка разнородных ресурсов на крае: предоставляет единый опыт для различных архитектур аппаратных средств краевых узлов (например, x86, ARM, RM64 и т.д.), спецификаций аппаратных средств и протоколов связи;
- Высокая надежность/стабильность: на основе автономности края и модульности краевых единиц обеспечивает непрерывную стабильную работу масштабируемых приложений на крае в нескольких регионах. Поддерживает различные открытые системы AI (например, TensorFlow, PyTorch и т.д.), что обеспечивает наилучший опыт для пользователей AI;
- Независимость от платформы облака: OpenYurt легко можно развернуть на любом Kubernetes-сервисе публичного облака;
- Одноклик-переход: один командный вызов для преобразования Kubernetes кластера в OpenYurt кластер.

#### 6.2.3 SuperEdge

![](images/superedge-arch.png)- Kubernetes-нativo: SuperEdge расширяет мощные возможности контейнерного планирования и расписания Kubernetes до краевых узлов без вторжения. Он полностью совместим с Kubernetes, поддерживает все API и ресурсы Kubernetes и не требует дополнительного обучения.
- Краевое автономное управление: SuperEdge предоставляет способность краевых узлов к автономному управлению уровня L3. Когда краевые узлы не имеют стабильного сетевого соединения с облаком или находятся в оффлайн-режиме, они могут автономно работать, преодолевая негативное влияние ненадежных сетей.
- Распределенное мониторинг здоровья узлов: SuperEdge — это первая открыто-исходная система управления контейнерами, которая предоставляет способность к мониторингу здоровья краевых узлов. SuperEdge может постоянно наблюдать за процессами на краевых узлах и собирать информацию о сбоях, обеспечивая более быстрое и точное обнаружение и отчет о проблемах. Кроме того, его распределенная архитектура позволяет осуществлять мониторинг и управление в нескольких регионах и диапазонах.
- Встроенные возможности краевого планирования: SuperEdge может автоматически развертывать микросервисы в нескольких регионах, что облегчает управление микросервисами, работающими в нескольких регионах.Кроме того, замкнутые циклы услуг в сетях могут эффективно снизить нагрузку на выполнение, повысив емкость системы к отказоустойчивости и надежности.

- Проникновение внутренней сети: SuperEdge обеспечивает непрерывную работу и обслуживание узлов Kubernetes в условиях наличия или отсутствия публичной сети, поддерживая одновременно протоколы TCP, HTTP и HTTPS.### 6.3 Платформа PaaS: KubeSphere

### 6.4 Платформа решения для AI в облаке

Sandbox-дизайн

### 6.5 Платформа решения для IoT в облаке

## 7 Часто задаваемые вопросы

1. Какие улучшения по размеру файла, потреблению CPU/памяти и энергопотреблению можно ожидать от K3S по сравнению с K8S?

    См. <https://rancher.com/docs/k3s/latest/en/installation/installation-requirements/resource-profiling/> для информации о том, что улучшение размера файла для K3S по сравнению с K8S не является значительным, но K3S облегчает минималистичное развертывание K8S. Минимальные требования к CPU и памяти для K3S превышают требования для K8S примерно на 50%.    См. <https://www.siderolabs.com/blog/is-vanilla-kubernetes-really-too-heavy-for-the-raspberry-pi/> для информации о том, что оптимизированный vanilla K8S имеет значительные преимущества по сравнению с K3S по CPU, а по памяти — преимущества незначительны. 2. Использование KubeEdge для оркестрации приложений на краевых узлах имеет уникальные преимущества:
     - Благодаря бизнес-логике, выполняемой на крае, можно обрабатывать большие объемы данных, создаваемых локально, и защищать их. Это снижает требования к пропускной способности сети между краем и облаком, ускоряет отклик, снижает затраты и защищает конфиденциальность данных клиентов.
     - Разработчики могут создавать обычные приложения на основе HTTP или MQTT, упаковывать их в контейнеры и запускать их на крае или в облаке в наиболее подходящем месте.
     - С помощью KubeEdge пользователи могут оркестрировать приложения, управлять устройствами и наблюдать за состоянием приложений и устройств на краевых узлах так же, как это делается в традиционных кластерах Kubernetes.
     - Существующие сложные приложения для машинного обучения, распознавания изображений, обработки событий и других продвинутых приложений можно легко развернуть на крае.
 3. Если краевое устройство вышло из строя, как приложение может автоматически переключиться на удаленный сервис? Можно настроить узкопряжевую аффинность, приоритизируя ближайшие узлы.Если ближайший узел Node отключается, Pod автоматически распределяется на удалённый. Для состоятельных приложений следует учитывать синхронизацию состояния с обеих сторон — ближайшей и удалённой.4. В реальных приложениях рекомендуется использовать edge cloud или cloud edge?

    Ссылка: http://blog.itpub.net/69912185/viewspace-2685097/Edge cloud: создание небольших облачных сервисных возможностей на краю, где основные сервисные возможности предоставляются краевым облаком, а централизованный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральныйЦентральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральныйЦентральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральныйЦентральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральныйЦентральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральныйЦентральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральныйЦентральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральныйцентральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный центральный Облачно-краевое взаимодействиеЦентральное облако и краевое облако взаимодействуют, позволяя центральному облаку управлять краевым облаком и обеспечивать его достаточным количеством виртуальных ресурсов.11. Каковы основные идеи k0s?
    - Нулевое трение (инструмент управления k0s, который предлагает больше функций, чем kubeadm): уменьшает сложность установки и запуска k8s, позволяя создать новый кластер за несколько минут. Снижает трение между разработчиками до нуля, что позволяет любому человеку легко начать работу с k8s, не имея специальных навыков или знаний.
    - Нулевая зависимость: распространяется в виде одного исполняемого файла, не завися от операционной системы, кроме ядра операционной системы хоста. Может работать с любой операционной системой без необходимости дополнительных пакетов или конфигураций. Любые уязвимости безопасности или проблемы производительности могут быть исправлены в выпуске k0s.
    - Нулевая стоимость: полностью бесплатен для личного и коммерческого использования.

12. Какой из вариантов — краевое облако или облачно-краевое решение — чаще используется в производственных системах?

    См. вопрос 4

13. Каковы различия в производительности между k3s и k8s?

    См. вопрос 1

14. Какие преимущества имеет решение Kata?

    См. <https://github.com/kata-containers/kata-containers/blob/main/docs/Limitations.md>

    Основное преимущество — это безопасность. Решение Kata избегает проблем безопасности и изоляции, связанных с использованием общего ядра в традиционных контейнерах, предоставляя каждому контейнеру возможность запускаться в легковесной виртуальной машине с отдельным ядром.15. Как k3s обеспечивает безопасность при минимизации размера?

    См. <https://docs.rancher.cn/docs/k3s/security/hardening-guide/_index>

    K3s применяет некоторые меры по улучшению безопасности по умолчанию, которые позволяют ему соответствовать некоторым контрольным точкам Kubernetes CIS без необходимости внесения изменений. Однако есть некоторые явные исключения, такие как изменения уровня хоста, которые необходимо выполнить вручную для полного соответствия стандартам CIS.

16. Может ли краевое облако k3s использовать Flannel для обеспечения взаимодействия сетей контейнеров с кластером k8s?

    Для обеспечения взаимодействия сетей контейнеров между различными кластерами k8s (k3s) требуется использование маршрутизации (статической маршрутизации или динамической маршрутизации, например BGP) или VPN. Такое требование не встречалось в производственных системах.17. Как обеспечивается конечная согласованность данных между краевым узлом и облаком при отключении краевого узла и множественных изменениях данных? Управление приложениями и другие операции в KubeEdge в настоящее время требуют прохождения через K8s master. Для сценария, когда краевые узлы находятся в оффлайн-режиме, предоставляется возможность автономной работы, то есть локально сохраняемые данные используются только для управления приложениями и устройствами на узле. При восстановлении связи между облаком и краем, узел синхронизирует локальные метаданные с обновленными данными, полученными от CloudCore.В этом контексте немного отличается управление краевыми устройствами. Установка ожидаемого состояния устройств осуществляется через Desired State в Device CRD (с облака на край), в то время как фактическое состояние устройств отображается в Reported State (с края на облако). Обмен данными в обоих направлениях не конфликтует.

18. Docker контейнерные образы для узлов края берутся из единого репозитория образов облака-края k8s системы?

    kubeedge узлы края могут получать образы из любого подключенного репозитория образов

19. Управление жизненным циклом k8s кластера применимо к k3s?

    применимо

20. Какие аспекты легковесности k3s по сравнению с k8s проявляются, и могут ли они сделать образы ещё более легковесными?
    - Использование SQLite базы данных вместо etcd
    - Минимизация внешних зависимостей, k3s требует только ядра и монтирование cgroup

    не могут

21. Может ли k3s решить проблему недоступности образов за границей?

    можно использовать внутренний репозиторий образов

22. Есть ли у k3s преимущества помимо безопасности?
    - Легковесность, подходит для развертывания на крае
    - Простота использования для пользователей

23. Какой масштаб cloud core может поддерживать в k3s edgecore?    | Масштаб развертывания | Узлы | VCPUS | Память |
    | ---------------------|------|-------|--------|
    | Малый                | до 10| 1     | 2 ГБ   |
    | Средний              | до 100| 2    | 8 ГБ   |
    | Большой              | до 250| 4    | 16 ГБ  |
    | X-Большой            | до 500| 8    | 32 ГБ  |
    | XX-Большой           | 500+  | 16   | 64 ГБ  |24. Как K3S обеспечивает безопасность данных? Как долго может быть прервано соединение с управляющим узлом?

    K3S представляет собой урезанную версию K8S и не отличается от K8S в обеспечении безопасности данных и времени простоя соединения.

25. С точки зрения пользователя, есть ли различия между облаком-краем и краем-облаком? Какой вариант предпочтительнее?

    Для пользователя управление пакетами в облаке-крае проще. Крае-облако более независимо от кластера. Каждый вариант имеет свои сценарии использования. В телекоммуникационных краевых вычислениях, где требуется размещение на базовой станции, независимое управление обычно предпочтительнее, поэтому чаще выбирается крае-облако.

26. Есть ли ограничения для отечественного использования лицензий открытого кода, таких как GPL, Apache и т.д.? Если да, есть ли риск для отечественных пожертвованных материалов?

    Есть, но вероятность низкая.

    Отечественные пожертвованные материалы не должны содержать рисков для использования.

27. Есть ли актуальные сценарии использования StarlingX?

    См. https://www.99cloud.net/11234.html

    Основные применения включают промышленные IoT, телекоммуникации, видео и другие сценарии с высокими требованиями к задержке. В Китае отсутствует экосистема.

28. Как долго kubeedge может обеспечивать автономную работу в офлайн-режиме?    Может обеспечивать длительную автономную работу благодаря сохранению состояния базы данных.

29. В каких компонентах k3s отличается от k8s по упрощению?

    См. https://github.com/k3s-io/k3s/blob/master/README.mdИнтеграция:

- Containerd & runc
- Flannel для CNI
- CoreDNS
- Metrics Server
- Traefik для ingress
- Klipper-lb как встроенный поставщик балансера нагрузки
- Kube-router для политики сети
- Helm-controller для развертывания манифестов Helm с использованием CRD
- Kine как шим для хранилища данных, который позволяет заменить etcd другими базами данных
- Local-path-provisioner для выделения томов с использованием локального хранилища
- Утилиты хоста, такие как iptables/nftables, ebtables, ethtool и socat

Удаление:

- Встроенные драйверы хранения
- Встроенные провайдеры облачных провайдеров

30. Каковы перспективы k3s и kubeedge?

Перспективы очень хорошие, так как многие устройства на краю сети не могут развернуть k8s, и они обходятся меньшими затратами по сравнению с k8s.

31. Какова степень зрелости применения k3s в отечественном развитии отрасли краевого вычисления?

Степень зрелости довольно высокая, и уже есть несколько успешных примеров внедрения.

32. Как k3s обеспечивает высокую пропускную способность?

Это не сильно отличается от k8s, k3s также может использовать несколько узлов для работы.

33. Какие примеры внедрения k3s существуют?

Промышленный интернет вещей, государственные банки.34. Какова производительность k3s, какую нагрузку он может выдержать?

Это не сильно отличается от k8s, k3s также может использовать несколько узлов.

35. Сколько edgecore может обслужить cloud core в kubeedge?

1:n

36. Сколько edged может обслужить edge core в kubeedge?

1:1

37. Где лучше размещать вычислительные узлы в краевой сети — на базовой станции 5G или после опускания UPF?

Лучше размещать после опускания UPF.

38. Какие примеры успешного внедрения краевой сети существуют?
- KubeEdge: использование Apache Beam для анализа данных
- Современное сельское хозяйство, например, посев, мониторинг роста растений
- Система городского мониторинга

39. Нужно ли поддерживать сеть KubeEdge в соответствии с K8S?

Да, это необходимо.

40. Полностью ли KubeVirt моделирует сетевую среду?

Каждый виртуальный машинный экземпляр соответствует одному pod, сетевая карта этого pod используется как виртуальная сетевая карта для виртуальной машины.

41. Каковы различия между отечественными решениями MEC и KubeEdge?

MEC-платформы обычно включают краевую облачную вычислительную среду и MEP, в то время как KubeEdge представляет собой облако-краевую архитектуру.

42. Каков масштаб поддерживаемых устройств KubeEdge?

По заявлению разработчиков, это тысячи узлов и миллионы подключений, но на каждом узле может быть подключено несколько тысяч устройств.43. В чем заключается легковесность k3s?
- Требования к диску меньше
- Требования к памяти ниже
- Удаление избыточных компонентов, программ и старого кода
- Использование SQLite вместо etcd
- Отсутствие зависимости от операционной системы, требуется только ядро и монтирование cgroup

44. В каком случае KubeEdge или K3S используется чаще в краевой сети?

Это зависит от конкретных требований, но K3s обычно используется чаще благодаря своей легковесности и простоте развертывания.

45. Управление центральным облаком периферийным облаком и управление периферийным облаком центральным облаком имеют свои преимущества и недостатки.

Управление центральным облаком периферийным облаком более распространено.

Управление периферийным облаком центральным облаком контролирует данные на периферии, что создает угрозу безопасности. Это обычно используется в случае временной необходимости использования эластичных вычислительных мощностей центрального облака, что не так распространено.

46. K3S по сравнению с K8S, какие компоненты и функции были упрощены?

То же, что и вопрос 29.

47. Какие способы управления жизненным циклом кластеров k3s и k8s рекомендованы?

Для k8s можно использовать kubeadmin / k0s.

K3S имеет свои инструменты управления жизненным циклом.

48. Какие рекомендации по взаимодействию контейнеров KubeEdge и K8S есть?Взаимодействие контейнеров KubeEdge и K8S уже предусмотрено.

49. Какие альтернативные продукты существуют для управления CRD операторами k8s помимо Helm?

https://docs.k0sproject.io/v1.22.3+k0s.0/manifests/

K0S: Манифест-деплойер

50. Исходя из требований к ресурсам и среде для k3s и k8s, какие отличительные преимущества k3s можно выделить?
- Требования к ресурсам и среде для k3s и k8s существенно различаются. K3S занимает меньше ресурсов, что делает его более подходящим для развертывания в условиях недостатка ресурсов на периферии;
- Для многих пользователей многие функции k8s не являются необходимыми. В этом случае k3s сохраняет только необходимые компоненты, а дополнительные компоненты пользователи могут установить самостоятельно, что делает k3s более конкурентоспособным;
- K3S проще в использовании и более дружественен к пользователям.

51. Какая безопасность у k3s по сравнению с k8s?

K3S просто упрощен, безопасность k3s по сравнению с k8s не сильно отличается.

52. Какие примеры использования k3s в России есть?

См. https://www.bilibili.com/video/BV1g7411G7By?from=search&seid=18067894859541366568&spm_id_from=333.337.0.0

Промышленный интернет вещей, государственные банки.

53. Несмотря на то, что задержка в вычислениях на периферии измеряется в миллисекундах, не является ли привлекательность для клиентов в первую очередь уникальностью и безопасностью оборудования и данных? Как вы считаете, какие преимущества имеет рынок вычислений на периферии?Основное преимущество вычислений на периферии — это низкая задержка. Хотя на оборудовании на периферии можно выполнять определенные вычисления данных, в конечном итоге данные все равно должны быть загружены на сервер, где можно выполнять определенные операции для обеспечения безопасности данных. Уникальность данных не так важна.

54. В каких сценариях применения KubeVirt имеет наивысшую ценность?

То же, что и вопрос 54.

55. Какие часто используемые порты для K3S?

- 6443: для доступа агента к серверу
- 8472: для взаимодействия узлов через Flannel VXLAN
- 10250: для метрик сервера
- 2379-2380: для etcd

56. Как избежать однопунктного отказа (single point of failure) для мастера в K3S? Высокодоступная архитектура, увеличение избыточности; отказы узлов难以避免

57. Как K3S гарантирует высокую надежность в одноподключенной архитектуре?

    Надежность означает способность выполнять заданные функции в заданных условиях и в заданное время. Это не связано с одноподключенной архитектурой.

    Одноподключенная архитектура не может гарантировать высокую доступность.

58. Какие требования к сети для синхронизации данных "облачного" и "крауда" в K3S? Это синхронизация с сильной согласованностью?

    K3S — это облачное крауд-решение, само по себе не требует координации "облачного" и "крауда". Координация "облачного" и "крауда" требует дополнительной облачной платформы управления.59. Какие основные архитектуры и программное обеспечение используются в адаптере облака в MEC?

    Разные облачные платформы предоставляют свои решения.

60. Какие преимущества, кроме нулевого вторжения, имеет OpenYurt?

    Основное преимущество — это экосистема. Также, для различных выпусков k8s сложно обеспечить полную поддержку.

    - Поддержка разнородных ресурсов крауда: для узлов крауда с различными архитектурами оборудования (например, x86, ARM, RM64 и т.д.), спецификациями оборудования и протоколами связи обеспечивается единый опыт;
    - Высокая надежность/стабильность: на основе автономности крауда и единичных модулей крауда обеспечивается стабильная работа масштабируемых приложений крауда в различных регионах. Поддерживает различные открытые системы AI (например, Tensorflow, Pytorch и т.д.), обеспечивая наилучший опыт для пользователей AI;
    - Независимость от облачной платформы: OpenYurt легко разворачивается в Kubernetes-сервисах любой публичной облачной платформы;
    - Однокнопочный переход: одной командой Kubernetes можно преобразовать в OpenYurt-кластер.

61. Почему DVR используется в производственных средах редко?

    DVR主要用于提升大规模集群的网络性能，避免集中网络节点的数据汇聚。但分布式带来了额外的网络复杂性，排查问题困难。

    "大规模集群"指的是1000个节点以上，这种规模不常见。通常500个节点为限，超过这个数量就需要分region处理。不会遇到网络性能瓶颈（通常先遇到的是MySQL或RabbitMQ的性能瓶颈）。62. Существуют ли крупномасштабные развертывания KubeVirt в производственных средах?

    Нет.

63. Какая разница между upgw и операторским upf?

    upgw проще, это просто серийный переключающийся гейтвей для радиосети.

64. Не все ли управление облачно-краудом происходит в облаке?

    Нет. KubeEdge расширяет нативные функции управления контейнерами до узлов крауда.

65. Как достигается инкрементальная синхронизация образов виртуальных машин?

    Инкрементальные образы сохраняют изменения в виртуальной машине в инкрементальных образах, а исходный образ остается неизменным.

66. Как обеспечить безопасность при использовании etcd, если соединение часто теряется и использование HTTPS замедляет работу? Изменение времени ожидания и использование SSD жесткого диска, обратите внимание, что оптимизация производительности является ключевым моментом, HTTPS обязательно использовать.

67. В каких конкретных случаях применим K3S?
    - Работа на краях сети
    - Интернет вещей
    - CI
    - Развертывание
    - ARM
    - Встроенное использование k8s

68. В каких случаях применим OpenYurt? Как он отличается от K8S и K3S?

    Ссылка: https://cloud.tencent.com/developer/article/1785922

    K8S разработан для центров обработки данных и имеет полный набор функций, но требует больше ресурсов; если вам нужно развернуть более сложные приложения на краях сети, выберите K8S.    K3S — это упрощенная версия K8S, которая требует меньше ресурсов и может быть независимо развернута на узлах края сети, что делает её подходящей для использования в краевых узлах, где требуется полный кластер (включая управляющий кластер).

    OpenYurt также является проектом краевой вычислительной сети, основанной на K8S, и имеет такие характеристики, как облачное управление краем, автономность края и т.д., что делает её более дешевой в обслуживании, чем K3S. Метод управления — облачное управление краем.

69. Есть ли хорошие книги по K3S?

    Посмотрите официальную документацию...

70. В управлении падами контейнеров на крае сети, кто контролирует распределение падов — краевая сеть или центральная сеть?

    Распределение падов контролируется краевой сетью, поскольку условия сети на крае часто нестабильны, и управление распределением падов центральной сетью может быть затруднительным.

71. Какие различия существуют между аппаратными требованиями краевой и центральной сетей?

    Аппаратные требования к центральной сети выше.

72. В каких случаях используется EdgeXFoundry?

    EdgeXFoundry используется в случаях, когда требуется подключение к большим количествам различных устройств и управление ими с помощью единой архитектуры, например, в промышленных интернетах вещей, умных стадионах, открытых системах управления недвижимостью.73. Как EdgeX Foundry применяется в смешанных облачных и MEC сценариях?

    Эмм, трудно понять точку вопроса, используйте официальную документацию? Рекомендую оставить issue.

74. Для каких MEC сценариев подходят Kubeedge и K3S?

    K3S часто используется в MEC сценариях. Тот же вопрос, что и в 4.

75. Какие данные хранятся в core data и meta data в архитектуре EdgeX Foundry?

    core data: данные промежуточного хранения, используются для передачи данных между севером и югом.

    meta data: информация о устройствах и сервисах.

76. Каким образом в EdgeX Foundry реализована безопасность?
    - секретное хранилище: для хранения зашифрованных данных в EdgeX. Примеры зашифрованных данных в EdgeX включают пароли доступа к базам данных, используемые другими службами для подключения к облачным системам.
    - API-шлюз: выполняет функции обратного прокси для доступа к ограниченному REST-ресурсу EdgeX, а также выполняет задачи управления доступом. Управление системой служб EdgeX обеспечивает центральную точку управления доступом для внешних систем управления, чтобы запускать/останавливать/перезапускать службы EdgeX, получать состояние/здоровье служб или метрики (например, использование памяти) для мониторинга служб EdgeX.

77. Какие решения для MEC уже используются?
    - EdgeX Foundry: интеллектуальный ритейл, мониторинг качества поверхности в производственных цехах, мониторинг промышленного оборудования
    - k3s: промышленный интернет вещей, государственный банк
    - KubeEdge: анализ данных с использованием Apache Beam78. Как можно обеспечить высокую доступность Redis?
    redis sentinel

    - Репликация master-slave
    - Кластер Redis
79. Передача зеркального изображения на краевые устройства не создает ли сетевое напряжение?

    Да

80. Есть ли применение k3s за рубежом?

    Да, часто используется на краевых устройствах

81. Каковы требования к сети для EdgeX Foundry?

    Не понимаю вопрос, рекомендую создать issue

82. Как EdgeX Foundry обеспечивает безопасность данных?
    - secret store: хранение паролей для подключения к облачным системам
    - API gateway: обратный прокси, ограничивающий доступ к ресурсам EdgeX REST и контролирующий доступ
83. Существует ли снижение производительности в реальных проектах из-за трехуровневой распределенной облачной операционной системы?

    Комплексная архитектура неизбежно приводит к снижению производительности, компромисс

84. Каковы ключевые различия между openYurt и kubeedge? По схемам это не очевидно

    openYurt представляет собой узел кластера k8s, находящийся на крае.

    KubeEdge представляет собой кластер k8s, где краевые узлы имеют базу данных для сохранения состояния

85. Поддерживает ли kubeedge архитектуру ARM для низкого энергопотребления?

    Да

86. Поддерживает ли EdgeX Foundry низкое энергопотребление?

    Да

87. Каковы различия между операторскими краевыми средами и IT-краевыми средами? Какие аспекты операторской архитектуры можно использовать для оптимизации?    Отсутствие или наличие базовых станций

88. Как решить проблему длинной цепочки логов при использовании Horizon как интерфейса?

    Через request id

89. Как безопасно осуществлять доступ и контроль через Core Services Layers и Supporting Services Layers?
90. Как подключить видеопотоки IP-камер и других устройств к EdgeX Foundry?

    См. https://www.edgexfoundry.club/user/lulililu/article/5d8d93356598210001292c9b

    Используйте edgex-device-rtsp

91. Какие устройства/датчики относятся к棕色设备 и绿色设备 в EdgeXFoundry?
    -棕色设备: старые устройства, использующие устаревшие протоколы
    -зелёные устройства: новые устройства, использующие современные протоколы
92. Какие наиболее ценные сценарии применения краевой вычислительной инфраструктуры существуют в настоящее время?

    5G + MEC + краевая вычислительная инфраструктура

93. Есть ли сценарии совместного использования kubeedge и k3s?

    Это не обязательно, выбирайте одно из них

94. Есть ли готовые решения для использования kubeedge в IoT?

    См. https://bbs.huaweicloud.com/blogs/241370Управление узлами края с использованием KubeEdge+K8S

95. В каких сценариях применяется вычисление на краю?

    Интернет вещей, промышленный интернет,车联网, 5G с минимальной задержкой

96. Какие компании хорошо работают с вычислением на краю?

    Amazon, Microsoft, Google, Alibaba Cloud, Huawei Cloud, China Mobile и другие

97. Есть ли ограничения на количество кластеров, управляемых Kubesphere?    Нет явных ограничений

98. Каковы решения для ошибок, связанных с нехваткой ресурсов в Kubeedge?
99. Технологические обновления происходят очень быстро. После контейнеризации, появились ли какие-либо новые технологии?

    Эммм, платформы с низким кодом?

    Технология контейнеризации фактически была реализована в VERTEX веке, основные изменения в компьютерах происходят медленно. Видимые изменения могут быть связаны с квантовым вычислением, которое может привести к фундаментальным изменениям. 

    Другие технологии, такие как车联网、无人机群、元宇宙, являются производными от этих изменений.

1. В каких сценариях используется вычисление на краю в настоящее время?

    Интернет вещей, промышленный интернет,车联网, 5G с минимальной задержкой

1. Как выбрать метод HA для Redis?

    В зависимости от потребностей бизнеса

2. Какие технологии используются для автоматического обнаружения краевых устройств?

    Подписка

3. В каких аспектах EdgeX Foundry оптимизирует задержку?
4. Почему C имеет лучшую производительность, чем Go?

    C: программисты могут самостоятельно управлять выделением и освобождением памяти

    Go: использует GC (механизм сборки мусора), компилятор сам управляет выделением и сборкой памяти5. Какие участники обычно участвуют в сценариях использования вычислений на краю, и какие обязанности они выполняют?

6. В каких аспектах недостаточно стандартизированы краевые вычисления в практике, и какие аспекты наиболее требуют стандартизации?    MP2 / MM5 интерфейсы

7. Какие различия между EdgeX Foundry и KubeEdge в контексте требований к интернету вещей?

    EdgeX Foundry лучше подходит для сценариев, где существует множество различных устройств, так как он может быть совместим с множеством различных протоколов.

8. Какие рекомендации для развития краевых облачных сервисов в телекоммуникациях?

    MEC+краевые облака, создание телекоммуникационной платформы PaaS, ориентированной на приложения.

9. Какие преимущества имеют токены JWT?

    - Основаны на JSON, что делает их удобными для анализа.
    - Можно добавлять богатые данные, легко расширяемые.
    - Защищены от подделки благодаря использованию алгоритмов асимметричного шифрования и цифровых подписей.
    - Сервисы могут быть авторизованы без необходимости обращения к службе аутентификации.

10. Какие возможности поддержки ARM имеют k3s/k8s?

    Оба поддерживают ARM.11. Как EdgeX Foundry обеспечивает безопасность?
    - vault: генерация корневого сертификата CA, сертификатов и ключей edgex-vault (поддержка HTTPS)
    - vault-worker: (если не существует) генерация сертификатов и ключей для kong, сохранение их в vault; отправка пульса жизни consul для проверки работоспособности vault
    - security-api-gateway: получение сертификатов из vault-сервера по токену и загрузка их на kong-сервер; управление пользователями kong, генерация JWT-строк
    - kong: обеспечение безопасного доступа к микросервисам edgexfoundry (после получения JWT доступ к микросервисам через JWT-строки)

12. С чем связаны требования к DevOps-профессионалам в связи с развитием AIOps-инструментов и процессов в облачной индустрии?
    - Опыт работы в отрасли
    - Навыки работы с AI13. Существуют ли хорошие руководства или сайты по k3s?

    См. вопрос 69

14. Какие применения имеет kubedge в области интернета вещей?

    См. https://bbs.huaweicloud.com/blogs/241370

    KubeEdge+K8S для управления краевыми узлами на автомагистралях

15. Когда стоит рассматривать использование краевого вычисления?

    Трудно дать точный ответ, но обычно это требуется, когда конечные устройства дешёвые и не имеют мощного вычислительного оборудования.

16. Необходимо ли дальнейшее развитие архитектуры краевого вычисления?

    Краевое вычисление ещё не широко распространено, поэтому его архитектура обязательно будет развиваться до оптимальной формы.

17. Какие существуют способы реализации Service Mesh?

    См. https://www.nginx.com/blog/what-is-a-service-mesh/

    Сторожевой режим, когда устанавливается промежуточный сервер для управления трафиком сервисов, который через коммуникацию между промежуточными серверами осуществляет коммуникацию между сервисами. Примеры: Linkerd, Envoy, Istio.18. Какие уровни архитектуры EdgeXFoundry соответствуют уровням в примере с умной спортивной ареной или открытым системой управления недвижимостью?
    - Уровень приложений:
        - Уровень отображения: U3D/UE4/web/App
        - Уровень поддержки приложений:
        - Уровень бизнеса: управление недвижимостью/офис
    - Уровень ядра:
        - IoT-платформа (EdgeX), пользователи, права доступа
        - Уровень адаптации IoT
        - IoT: внешние интерфейсы IoT
        - Уровень сети: BA/Bodbus/Zigbee/NBIoT/HTTP
    - Уровень устройств:
        - Уровень сенсоров: устройства (датчики)

OSCHINA-MIRROR/dev-99cloud-training-kubernetes .gitee-modal { min-width: 500px !important; } .gitee-modal .close { right: 0.6rem !important; }

Решение Edge Container Cloud

1. Крайнее вычисление и K8S

1.1 Анализ отрасли краевого вычисления

1.1.1 Эволюция архитектуры вычислительных систем за 60 лет

1.2 Архитектура краевого вычисления

1.2.1 MEC-краевая облако

1.2.2 Облачное краевое вычисление

Основные требования:

Техническая архитектура:

1.3 Проблемы краевых решений

1.3.1 Отсутствие феноменальных краевых приложений

1.3.2 Краевое облако должно поддерживать гетерогенные аппаратные средства

1.3.3 K8S для края

2. Решение K3S

2.1 Основные понятия K3S

2.1.1 Что такое K3S

2.2 Развертывание K3S

2.2.1 Одноузловой архитектурный подход

2.2.2 Подготовка к развертыванию

2.2.3 Одноузловой подход к развертыванию

curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="--docker" sh -

Изменение режима CNI

По умолчанию K3s использует flannel в качестве CNI с VXLAN в качестве стандартного режима. Для изменения режима CNI используйте следующие команды:

--flannel-backend=vxlan (по умолчанию) Использует VXLAN режим.

--flannel-backend=ipsec Использует IPSEC режим для шифрования сетевого трафика.

--flannel-backend=host-gw Использует режим host-gw.

--flannel-backend=wireguard Использует режим WireGuard для шифрования сетевого трафика. Может потребоваться дополнительное оборудование и настройка.

2.3 Управление краем от центра

2.3.2 Условия узлов

2.3.3 Развертывание K3S и Rancher

2.3.4 Управление K3S

2.4 Использование K3S в CI/CD

2.4.1 Развертывание

--no-deploy=traefik по умолчанию включает Traefik, поэтому его не нужно развертывать

--kube-apiserver-arg=feature-gates=RemoveSelfLink=false для включения NFS-хранилища, которое требуется для K8s версии 1.20 и выше

2.4.2 Регистрация

2.4.3 Развертывание Gogs

2.4.4 Развертывание Drone

2.4.6 Приложение YAML```markdown

Измените ${NODE_IP} в yaml на фактический IP текущей среды

замените на namespace, где развернут provisioner

namespace: default

замените на namespace, где развернут provisioner

замените на namespace, где развернут provisioner

замените на namespace, где развернут provisioner

замените на namespace, где развернут provisioner

2.5 Высокодоступное решение для K3S

2.5.1 Высокодоступная архитектура

2.5.2 Конфигурация высокодоступного развертывания

2.5.3 Развертывание внешней базы данных etcd

2.5.4 Сервер HA

2.5.5 Добавление агента

2.5.6 Удаление K3S

2.5.7 Приложение

/etc/systemd/system/etcd.service

etcd-ip: IP текущего узла

etcd1-ip: IP текущего узла

etcd2-ip: IP второго узла

etcd3-ip: IP третьего узла

3.4 Анализ кей-кейсов KubeEdge

3.4.1 Анализ данных с использованием Apache Beam

3.4.2 Почему используется Apache Beam для анализа

3.4.3 Demo: Реальное время оповещение: чтение и фильтрация данных из MQTT, и создание оповещений

3.4.4 Demo: Фильтрация потоковых данных. Чтение потоковых данных из MQTT, периодическая фильтрация

3.4.6 Проверка данных

3.5 Принципы и применение CloudCore

3.5.1 CloudHub

3.6.1 Edged

3.6.2 EdgeHub

3.6.3 MetaManagerMetaManager — это обработчик сообщений между edged и edgehub. Он также отвечает за хранение метаданных в легковесной базе данных (SQLite) или за их извлечение.

3.6.4 DeviceTwin

3.6.5 Eventbus

3.6.6 ServiceBus

4. Решение EdgeX Foundry

4.1 Введение в EdgeX Foundry

4.1.4 Слой поддерживающих сервисов

4.1.6 Уровень сервисов устройствУровень сервисов устройств соединяет "вещи" (сенсоры и устройства) с EdgeX.

4.1.7 Уровень системных сервисов

4.2 Развертывание EdgeX Foundry

OSCHINA-MIRROR/dev-99cloud-training-kubernetes