Реализация мультикластерного управления трафиком на базе istio

Ухань Юань Чуанхуэй возвращается, поговорим о больших моделях 20 апреля»

Эта статья опубликована автором в облачном сообществе Huawei « Реализация многокластерного управления трафиком на основе Istio »: Вы можете найти друга.

задний фон

Управление услугами для гетерогенной инфраструктуры, такой как мультиоблачная и гибридная облачная среда, — это один из сценариев, на поддержке которых Istio фокусируется. Чтобы повысить доступность услуг и избежать привязки к поставщику, предприятия обычно предпочитают развертывать приложения в нескольких кластерах в нескольких регионах или даже в нескольких облачных средах, таких как мультиоблачные и гибридные облачные решения, которые постепенно стали лучшими. выбор для развертывания корпоративных приложений. Таким образом, все больше и больше пользователей предъявляют серьезные требования к межкластерному управлению сервисами. В этом контексте Istio, являясь фактическим стандартом в области ServiceMesh, запустил множество решений для управления несколькими кластерами.

2. Введение

На данный момент Istio поддерживает 4 мультикластерные модели.

1. Модель единой плоскости управления плоской сети
2. Модель плоской плоскости с несколькими управлениями в плоской сети
3. Модель неплоской сети с единой плоскостью управления
4. Модель неплоской сети с несколькими плоскостями управления

Модель мультикластера с единой плоскостью управления означает, что несколько кластеров используют одну и ту же плоскость управления Istio. Модель мультикластера с несколькими плоскостями управления означает, что каждый кластер должен независимо использовать набор плоскостей управления Istio, независимо от того, является ли он единым элементом управления. плоскости или модели с несколькими плоскостями управления, каждый набор плоскостей управления Istio (istiod) должен быть подключен к Kube-apiserver всех кластеров, а List-Watch получает все кластеры Service、Endpoint、Pod 、Node и контролирует доступ к сервисам внутри кластера или между кластерами, но отслеживает только VirtualService、DestinationRule、Gatewayобъекты Istio API основного кластера.

В зависимости от того, является ли межкластерная сеть плоской или нет, Istio подразделяет две модели плоскости управления:

• Плоская сеть: мультикластерные контейнерные сети соединены через VPN и другие технологии, и поды могут получать прямой доступ между кластерами.
• Неплоская сеть: контейнерные сети каждого кластера изолированы друг от друга. Межкластерный доступ не может осуществляться и должен проходить через шлюз «восток-запад».

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

В этом документе для инструкций по установке выбрана модель неплоской сети с несколькими плоскостями управления: Модель установки с

несколькими плоскостями управления неплоской сетью имеет следующие характеристики.

1. Разные кластеры не обязательно должны находиться в одной большой сети, то есть контейнерную сеть не нужно соединять на трех уровнях, а доступ к межкластерному сервису осуществляется через Istio East-West Gatewayпереадресацию.
2. Нет ограничений на диапазон адресов подов и диапазон адресов служб каждого кластера Kubernetes. Он может перекрываться с другими кластерами, и разные кластеры не мешают друг другу.
3. Sidecar каждого кластера Kubernetes подключен только к плоскости управления Istio этого кластера, что делает взаимодействие более эффективным.
4. Istiod отслеживает конфигурацию Istio только основного кластера, поэтому возникают проблемы с избыточной репликацией для других ресурсов. VirtualService、DestinationRule、Gateway 
5. Доступ к внутренним службам в одном кластере: прямое соединение между модулями; доступ к службам между кластерами: использование DNS-прокси для разрешения доменных имен служб других кластеров. Поскольку сети между кластерами изолированы друг от друга, они полагаются на транзитный трафик. Удаленный кластер. East-west Gateway

Создание трех сред ClusterMesh

Создайте два кластера, кластер1 и кластер2, а затем установите плоскость управления Istio в каждом кластере и назначьте оба кластера основными. Кластер кластер1 находится в сети network1, а кластер кластер2 — в сети network2.

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

Информация о среде для этой сборки следующая: используйте Kind для создания кластера Kubernetes, а версия Kind — v0.19.0. Версия Kubernetes — 1.27.3, версия Istio — 1.20.1.

Перед созданием кластера k8s убедитесь, что на узле Linux установлены docker kubectl и kind.

Загрузите бинарный файл istioctl

curl -L https://istio.io/downloadIstio | ISTIO_VERSION=1.20.1 TARGET_ARCH=x86_64 sh -
Добавить клиент istioctl в путь

3.2 Установка кластера Kubernetes

Сценарии установки кластера Cluster1 и Cluster2 следующие:

# создать-кластер.sh
# Этот скрипт обрабатывает создание нескольких кластеров, используя вид и
# возможность создавать и настраивать небезопасный реестр контейнеров.

установить -o xtrace
set -o поднял
набор -о существительное
set -o пайпфейл

# проверка исходного кода =util.sh
NUM_CLUSTERS="${NUM_CLUSTERS:-2}"
KIND_IMAGE="${KIND_IMAGE:-}"
KIND_TAG="${KIND_TAG:-v1.27.3@sha256:3966ac761ae0136263ffdb6cfd4db23ef8a83cba8a463690e98317add2c9ba72}"
ОС="$(неимя)"
функция create-clusters() {
  локальный num_clusters=${1}

  локальный image_arg=""
  если [[ "${KIND_IMAGE}" ]]; затем
    image_arg="--image=${KIND_IMAGE}"
  элиф [[ "${KIND_TAG}" ]]; затем
    image_arg="--image=kindest/node:${KIND_TAG}"
  быть
  for i in $(seq "${num_clusters}"); делать
    типа создайте кластер --name "cluster${i}" "${image_arg}"
    кластер исправлений "${i}"
    эхо

  сделанный
}

функция fixup-cluster() {
  local i=${1} # номер кластера

  if [ "$OS" != "Дарвин" ];то
    # Установите IP-адрес контейнера в качестве конечной точки API Kube, чтобы кластеры могли обращаться к серверам API Kube в других кластерах.
    локальный docker_ip
    docker_ip=$(docker Inspect --format='{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' "cluster${i}-control-plane")
    Конфигурация kubectl set-cluster "kind-cluster${i}" --server="https://${docker_ip}:6443"
  быть

  # Упростить имя контекста
  kubectl config rename-context "kind-cluster${i}" "cluster${i}"
}
echo "Создание кластеров ${NUM_CLUSTERS}"
создать кластеры "${NUM_CLUSTERS}"
Конфигурация kubectl с использованием контекста кластера1

echo "Вид CIDR равен $(docker network Inspect -f '{{$map := index .IPAM.Config 0}}{{index $map "Subnet"}}' kind)"

эхо "Завершено"

Во время описанного выше процесса установки кластера, чтобы istiod мог получить доступ apiserverк адресу другого кластера, kube-apiserverадрес кластера устанавливается равным адресу главного узла. Поскольку это кластер, развернутый по типу, главные узлы двух кластеров по сути представляют собой контейнеры, на которых работает Docker на одном хосте.

Подтвердите, готовы ли кластер1 и кластер2

3.3 Используйте MetalLB для выделения внешнего IP-адреса шлюзу

Поскольку kind используется для развертывания нескольких кластеров, создание шлюза istio «север-юг» и шлюза «восток-запад» требует создания службы LoadBalencer, оба из которых требуют использования внешнего IP-адреса. Здесь metalLB используется для реализации распределения и объявления IP-адресов LB.
См. вид, чтобы создать кластер с использованием сегмента подсети узла: развертывание в режиме MetalLB L2. 172.18.0.0/16

Список конфигурации metalLB в кластере1: metalb-config-1.yaml

### для кластера1
##Настройте IPAddressPool для выделения адресов lbip. В режиме L2 адрес ippool и рабочий узел могут находиться в одной подсети.
apiVersion: metalb.io/v1beta1
вид: IPAddressPool
метаданные:
  название: первый пул
  пространство имен: metallb-система
спецификация:
  адреса:
    - 172.18.1.230-172.18.1.240
---
##Настройте L2Advertisement для объявления адреса
apiVersion: metalb.io/v1beta1
вид: L2Реклама
метаданные:
  имя: первое объявление
  пространство имен: metallb-система
спецификация:
  IP-адреспулы:
    - первый бассейн

Список конфигурации metalLB в кластере кластера2: metalb-config-2.yaml

### для кластера2
##Настройте IPAddressPool для выделения адресов lbip. В режиме L2 адрес ippool и рабочий узел могут находиться в одной подсети.
apiVersion: metalb.io/v1beta1
вид: IPAddressPool
метаданные:
  название: второй пул
  пространство имен: metallb-система
спецификация:
  адреса:
    - 172.18.1.241-172.18.1.252
---
##Настройте L2Advertisement для объявления адреса
apiVersion: metalb.io/v1beta1
вид: L2Реклама
метаданные:
  имя: второе наречие
  пространство имен: metallb-система
спецификация:
  IP-адреспулы:
    - второй бассейн

Установить с помощью скрипта

#!/usr/bin/env bash

установить -o xtrace
set -o поднял
набор -о существительное
set -o пайпфейл

NUM_CLUSTERS="${NUM_CLUSTERS:-2}"
для я в $(seq "${NUM_CLUSTERS}"); делать
  echo "Начинаем развертывание Metallb в кластере${i}"
  kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.13.10/config/manifests/metallb-native.yaml --context "cluster${i}"
  kubectl create secret generic -n metallb-systemmemberlist --from-literal=secretkey="$(openssl rand -base64 128)" --context "cluster${i}"
  ## Увеличьте время ожидания.Если загрузка metallb не развернута, при создании IPAddressPool L2Advertisement будет сообщено об ошибке.
  спать 10
  kubectl apply -f ./metallb-config-${i}.yaml --context "cluster${i}"
  эхо "----"
сделанный

Подтвердите статус развертывания metalLB

Подтвердите информацию IPAddressPool:

3.4 Доверительные отношения конфигурации общего корневого центра сертификации кластера

Для поддержки безопасной межкластерной связи mTLS модель с несколькими плоскостями управления требует, чтобы плоскость управления Istiod каждого кластера использовала промежуточный сертификат ЦС, выданный тем же центром ЦС, чтобы Citatel мог выдавать сертификаты для поддержки двунаправленной аутентификации TLS между кластерами. .

Шлюз Istio восток-запад (межкластерный доступ) при работе использует маршрутизацию на основе SNI. Он автоматически маршрутизирует ее в Кластер, соответствующий SNI, на основе SNI, запрошенного TLS. Поэтому межсетевой доступ в неплоских сетях требует, чтобы весь трафик был зашифрован TLS.

Вставляем сертификат и ключ в кластер.Сценарий следующий (скрипт необходимо переместить в каталог установочного пакета istio):

#!/usr/bin/env bash

установить -o xtrace
#set -o поднял
набор -о существительное
set -o пайпфейл
NUM_CLUSTERS="${NUM_CLUSTERS:-2}"
##Создайте каталог в каталоге верхнего уровня установочного пакета istio для хранения сертификатов и ключей.
mkdir -p сертификаты
pushd-сертификаты

##Сгенерировать корневой сертификат и ключ
make -f ../tools/certs/Makefile.selfsigned.mk root-ca

для я в $(seq "${NUM_CLUSTERS}"); делать
  ##Для каждого кластера сгенерируйте промежуточный сертификат и ключ для центра сертификации Istio.
  make -f ../tools/certs/Makefile.selfsigned.mk "cluster${i}-cacerts"
  ##Для каждого кластера создайте пространство имен istio-system
  kubectl создать пространство имен istio-system --context "cluster${i}"
  ## Для каждого кластера добавьте сетевую идентификацию, пометив пространство имен системы istio тегом topology.istio.io/network.
  kubectl --context="cluster${i}" пространство имен меток istio-system topology.istio.io/network="network${i}"
  ##Для каждого кластера пометьте узел рабочего узла регионом и зоной доступности, чтобы облегчить с помощью istio реализацию регионального аварийного переключения и региональной балансировки нагрузки.
  kubectl --context="cluster${i}" узел метки "cluster${i}-control-plane" topology.kubernetes.io/region="region${i}"
  kubectl --context="cluster${i}" узел метки "cluster${i}-control-plane" topology.kubernetes.io/zone="zone${i}"
  #В каждом кластере создайте частные сертификаты, используя все входные файлы ca-cert.pem, ca-key.pem, root-cert.pem и cert-chain.pem.
  kubectl удалить секретные cacerts -n istio-system --context "cluster${i}"
  kubectl create secret generic cacerts -n istio-system --context "cluster${i}" \
      --from-file="cluster${i}/ca-cert.pem" \
      --from-file="cluster${i}/ca-key.pem" \
      --from-file="cluster${i}/root-cert.pem" \
      --from-file="cluster${i}/cert-chain.pem"
  эхо "----"
сделанный

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

3.5 Установка сервисной сетки Istio

Установите сетку istio с несколькими плоскостями управления для кластеров кластера 1 и кластера 2.

Установите кластер1 в качестве основного кластера и выполните следующую команду в каталоге установки istio.

кот <<EOF > кластер1.yaml
apiVersion: install.istio.io/v1alpha1
вид: IstioOperator
спецификация:
  ценности:
    Глобальный:
      идентификатор сетки: сетка1
      multiCluster: ##Включить мультикластерную конфигурацию
        имя_кластера: кластер1 #Укажите имя кластера k8s
      network: network1 #Укажите идентификатор сети
      Ведение журнала:
        уровень: отладка
ЭОФ

Установите кластер2 в качестве основного кластера и выполните следующую команду в каталоге установки istio.

кот <<EOF >uster2.yaml
apiVersion: install.istio.io/v1alpha1
вид: IstioOperator
спецификация:
  ценности:
    Глобальный:
      идентификатор сетки: сетка2
      multiCluster: ##Включить мультикластерную конфигурацию
        имя_кластера: кластер2 #Укажите имя кластера k8s
      network: network2 #Укажите идентификатор сети
      Ведение журнала:
        уровень: отладка
ЭОФ

Написание сценариев автоматической установки.

#!/usr/bin/env bash

установить -o xtrace
set -o поднял
набор -о существительное
set -o пайпфейл

ОС="$(неимя)"
NUM_CLUSTERS="${NUM_CLUSTERS:-2}"

для я в $(seq "${NUM_CLUSTERS}"); делать

echo "Запуск развертывания istio в кластере${i}"

istioctl install --force --context="cluster${i}" -f "cluster${i}.yaml"

echo "Создать шлюз восток-запад в кластере ${i}"

## Установите шлюзы восток-запад в каждом кластере.
образцы bash/multicluster/gen-eastwest-gateway.sh \
--mesh "mesh${i}" --cluster "cluster${i}" --network "network${i}" | \
istioctl --context="cluster${i}" install -y -f -

эхо

сделанный

Выполните сценарий для установки и развертывания istio.

Подождите некоторое время, пока установка завершится

Вы можете обнаружить, что информация о внешнем IP-адресе, используемая шлюзом в каждом кластере, представляет собой адрес в IPPool, установленный настроенным metalLB.

3.6 Открытие услуг на шлюзе восток-запад

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

apiVersion: networking.istio.io/v1beta1
вид: Шлюз
метаданные:
  имя: межсетевой шлюз
спецификация:
  селектор:
    istio:eastwestgateway # Выделенный шлюз для трафика восток-запад
  серверы:
    - порт:
        номер: 15443 # Уже объявлено
        имя: спасибо
        протокол: TLS
      спасибо:
        mode: AUTO_PASSTHROUGH # Рабочий режим шлюза восток-запад — TLS AUTO_PASSTHROUGH.
      хозяева:
        - "*.local" # Открыть все сервисы

Примените вышеуказанную конфигурацию шлюза в каждом кластере отдельно:
kubectl -n istio-system --context=cluster${i} apply -f samples/multicluster/expose-services.yaml

3.7 Настройте секрет, чтобы istiod мог получить доступ к API-серверу удаленного кластера

Istiod в каждом кластере k8s должен просмотреть список Kube-APIServer других кластеров и использовать учетные данные кластера K8s для создания секретного объекта, чтобы позволить Istio получить доступ к удаленному API-серверу Kubernetes.

#!/usr/bin/env bash

установить -o xtrace
set -o поднял
набор -о существительное
set -o пайпфейл
ОС="$(неимя)"
NUM_CLUSTERS="${NUM_CLUSTERS:-2}"

для я в $(seq "${NUM_CLUSTERS}"); делать
  для j в $(seq "${NUM_CLUSTERS}"); делать
    если [ "$i" -ne "$j"]
    затем
      echo "Включить обнаружение конечных точек между кластером${i} и кластером${j}"

      if [ "$OS" == "Дарвин" ]
      затем
        # Установите IP-адрес контейнера в качестве конечной точки API Kube, чтобы кластеры могли обращаться к серверам API Kube в других кластерах.
        docker_ip=$(docker Inspect -f '{{range.NetworkSettings.Networks}}{{.IPAddress}}{{end}}' "cluster${i}-control-plane")
        istioctl create-remote-secret \
        --context="cluster${i}" \
        --server="https://${docker_ip}:6443" \
        --name="cluster${i}" | \
          kubectl apply --validate=false --context="cluster${j}" -f -
      еще
        istioctl create-remote-secret \
          --context="cluster${i}" \
          --name="cluster${i}" | \
          kubectl apply --validate=false --context="cluster${j}" -f -
      быть
    быть
  сделанный
сделанный

Выполните приведенный выше сценарий: удаленный секрет создан.

Проверьте журнал istiod и обнаружите, что удаленный кластер уже отслеживается.

Четыре практики управления многокластерным трафиком Istio

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

kubectl create --context=cluster1 пример пространства имен
kubectl create --context=cluster2 пример пространства имен

kubectl label --context=cluster1 пример пространства имен \
    istio-инъекция = включено
kubectl label --context=cluster2 пример пространства имен \
    istio-инъекция = включено

kubectl применить --context=cluster1 \
    -f образцы/helloworld/helloworld.yaml \
    -l service=helloworld -n пример
kubectl применить --context=cluster2 \
    -f образцы/helloworld/helloworld.yaml \
    -l service=helloworld -n пример

Развертывание разных версий сервисов в разных кластерах.

Разверните приложение helloworld-v1 в кластере1:

kubectl применить --context=cluster1 \
    -f образцы/helloworld/helloworld.yaml \
    -l версия=v1 -n образец

Разверните приложение helloworld-v2 в кластере2:

kubectl применить --context=cluster2 \
-f образцы/helloworld/helloworld.yaml \
-l версия=v2 -n образец

Развертывание тестового клиента

kubectl применить --context=cluster1 \
    -f образцы/sleep/sleep.yaml -n образец
kubectl применить --context=cluster2 \
    -f образцы/sleep/sleep.yaml -n образец

Убедитесь, что экземпляр загрузки успешно развернут и добавлена ​​дополнительная версия.

4.1 Проверка межкластерного трафика

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

Отправьте запрос к сервису HelloWorld из модуля Sleep в кластере1.

Отправьте запрос к сервису HelloWorld из модуля Sleep в кластере2.

4.3 Проверка доступа со шлюза

Доступ к серверу Helloworld через шлюз

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

# helloworld-gateway.yaml
apiVersion: networking.istio.io/v1beta1
вид: Шлюз
метаданные:
  имя: helloworld-шлюз
спецификация:
  селектор:
    istio: ingressgateway # использовать контроллер istio по умолчанию
  серверы:
    - порт:
        номер: 80
        имя: http
        протокол: HTTP
      хозяева:
        - "*"
---
apiVersion: networking.istio.io/v1beta1
вид: VirtualService
метаданные:
  имя: приветмир
спецификация:
  хозяева:
    - "*"
  шлюзы:
    - helloworld-шлюз
  http:
    - соответствовать:
        - тип:
            точно: /привет
      маршрут:
        - место назначения:
            хозяин: приветмир
            порт:
              номер: 5000

Примечание. Эту конфигурацию необходимо применить к обоим кластерам.

Эффект доступа следующий:

4.3 Проверка региональной балансировки нагрузки

Для более детального контроля над трафиком установите веса двух регионов на 80% и 20% соответственно и используйте DestinationRule для настройки распределения веса . region1 -> zone1  region1 -> zone2 

# locality-lb-weight.yaml
apiVersion: networking.istio.io/v1beta1
вид: DestinationRule
метаданные:
  имя: приветмир
  пространство имен: образец
спецификация:
  хост: helloworld.sample.svc.cluster.local
  Политика трафика:
    Пул соединений:
      http:
        Максрекуестсперконнектион: 1
    балансировщик нагрузки:
      просто: ROUND_ROBIN
      localityLbSetting:
        включено: правда
        распространять:
          - из: регион1/*
            к:
              "регион1/*": 80
              "регион2/*": 20
          - из: регион2/*
            к:
              "регион2/*": 80
              "регион1/*": 20
    Обнаружение выброса:
      последовательные5xxErrors: 1
      интервал: 1 с
      базовое время выброса: 1 м

Примечание. Эту конфигурацию необходимо применить к обоим кластерам.

Отправьте запрос к сервису HelloWorld из кластера1 через шлюз.

Отправьте запрос в сервис HelloWorld из кластера2 через шлюз

4.4 Проверка регионального аварийного переключения

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

# locality-lb-failover.yaml
apiVersion: networking.istio.io/v1beta1
вид: DestinationRule
метаданные:
  имя: приветмир
  пространство имен: образец
спецификация:
  хост: helloworld.sample.svc.cluster.local
  Политика трафика:
    Пул соединений:
      http:
        maxRequestsPerConnection: 1 # Отключить HTTP Keep-Alive и заставить каждый HTTP-запрос использовать новую политику подключения.
    балансировщик нагрузки:
      просто: ROUND_ROBIN
      localityLbSetting: # Конфигурация региональной балансировки нагрузки, после включения обнаружения выбросов она включается по умолчанию.
        включено: правда     
        аварийное переключение: # Региональная стратегия аварийного переключения
          - из: регион 1  
            в: регион2
          - из: регион 2
            в: регион1
    Обнаружение выброса:
      последовательные5xxErrors: 1 # 1 последовательная ошибка 5xx
      интервал: 1 с # Интервал обнаружения 1 с
      baseEjectionTime: 1m #Базовое время выброса 1m

Примечание. Эту конфигурацию необходимо применить к обоим кластерам.

Отправьте запрос к сервису HelloWorld из кластера1 через шлюз.

Смоделируйте сбой и вручную установите версию Helloworld V1 в кластере кластера1 на сбой.

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

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

Пять замечаний

Ссылки следующие:

1. Сообщество открытого исходного кода istio (инструкции по установке для межсетевой многоосновной архитектуры):  https://istio.io/latest/zh/docs/setup/install/multicluster/multi-primary_multi-network/

2. Ссылка на сценарий кластера установки вида: https://github.com/cnych/multi-cluster-istio-kind/tree/main/kind-create 

3. Справочник по управлению сертификатами нескольких кластеров: https://istio.io/latest/zh/docs/tasks/security/cert-management/plugin-ca-cert/

Нажмите, чтобы подписаться и узнать о новых технологиях Huawei Cloud как можно скорее~

 

Первое крупное обновление JetBrains 2024 (2024.1) имеет открытый исходный код. Даже Microsoft планирует платить за него. Почему его до сих пор критикуют за открытый исходный код? [Восстановлено] Сбой серверной части Tencent Cloud: большое количество ошибок обслуживания и отсутствие данных после входа в консоль. Германия также должна быть «независимо управляемой». Правительство штата перевело 30 000 компьютеров с Windows на Linux deepin-IDE и, наконец, добилось начальная загрузка! Выпущен Visual Studio Code 1.88. Молодец, Tencent действительно превратила Switch в «мыслящую обучающуюся машину». Удаленный рабочий стол RustDesk запускает и реконструирует веб-клиент. Терминальная база данных WeChat с открытым исходным кодом, основанная на SQLite, WCDB, получила серьезное обновление.

{{o.name}}

{{м.имя}}