Поради щодо розгортання

2 хвилин(и)

Ми визначили наступні загальні принципи, які допоможуть вам максимально ефективно використовувати ваші розгортання Istio. Ці поради спрямовані на обмеження впливу поганих конфігураційних змін і спрощення управління вашими розгортаннями.

Розгортайте менше кластерів

Розгорніть Istio на невеликій кількості великих кластерів, а не на великій кількості малих кластерів. Замість того, щоб додавати кластери до вашого розгортання, найкращою практикою є використання орендної моделі простору імен для управління великими кластерами. Відповідно до цього підходу, ви можете розгорнути Istio на одному або двох кластерах на зону або регіон. Потім ви можете розгорнути панель управління на одному кластері на регіон або зону для підвищення надійності.

Розгортайте кластери ближче до ваших користувачів

Включайте кластери у вашому розгортанні по всьому світу для географічної близькості до кінцевих користувачів. Близькість допомагає вашому розгортанню мати низьку затримку.

Розгортайте в кількох зонах доступності

Включайте кластери у вашому розгортанні в кількох зонах доступності та регіонах в кожному географічному регіоні. Цей підхід обмежує розмір домену відмов вашого розгортання і допомагає уникнути глобальних збоїв.

Запуск кількох реплік istiod

Зазвичай istiod розгортається з однією реплікою. Коли ця репліка стає недоступною — наприклад, під час очищення вузла або оновлення з перезапуском — вебхук мутації для інʼєкції sidecar (failurePolicy: Fail) відхиляє всі запити на створення podʼа у всьому кластері. Це фактично робить одну репліку istiod єдиною точкою відмови для будь-якої операції, яка створює pod.

Щоб уникнути цього, встановіть autoscaleMin не менше ніж 2 у вашому перевизначенні значень Helm для чарту istio/istiod. Чарт постачається стандартно з autoscaleEnabled: true, тому Horizontal Pod Autoscaler керує кількістю реплік. Встановлення мінімуму на 2 гарантує, що принаймні одна репліка залишається доступною під час збоїв:

autoscaleMin: 2

Додайте наступне до вашого перевизначення значень Helm для чарту istio/istiod, щоб розподілити репліки між вузлами та зонами. Використовуйте requiredDuringSchedulingIgnoredDuringExecution для розділення на рівні вузлів, щоб гарантувати, що репліки працюють на різних вузлах. Якщо потужності недостатньо, невідкладений pod виявляє проблему замість того, щоб мовчки розміщувати обидві репліки на одному вузлі. Використовуйте preferredDuringSchedulingIgnoredDuringExecution для розподілу на рівні зон, щоб уникнути блокування планування в кластерах із меншою кількістю зон, ніж реплік:

affinity:
  podAntiAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
    - labelSelector:
        matchExpressions:
        - key: app
          operator: In
          values:
          - istiod
      topologyKey: kubernetes.io/hostname
    preferredDuringSchedulingIgnoredDuringExecution:
    - weight: 100
      podAffinityTerm:
        labelSelector:
          matchExpressions:
          - key: app
            operator: In
            values:
            - istiod
        topologyKey: topology.kubernetes.io/zone