නිෂ්පාදනයේදී Kubernetes භාවිතයෙන් Istio ධාවනය කරන්නේ කෙසේද. 1 කොටස

කුමක්ද ඉස්ටියෝ? ජාලය හරහා වියුක්ත ස්තරයක් එකතු කරන තාක්ෂණයක් වන ඊනියා සේවා දැලක් මෙයයි. අපි පොකුරේ ඇති ගමනාගමනයේ සම්පූර්ණ හෝ කොටසක් බාධා කර එය සමඟ යම් මෙහෙයුම් මාලාවක් සිදු කරන්නෙමු. කුමන එක ද? උදාහරණයක් ලෙස, අපි ස්මාර්ට් මාර්ගගත කිරීම සිදු කරන්නෙමු, නැතහොත් අපි පරිපථ කඩන ප්‍රවේශය ක්‍රියාත්මක කරමු, අපට “කැනරි යෙදවීම” සංවිධානය කළ හැකිය, ගමනාගමනයේ නව අනුවාදයකට අර්ධ වශයෙන් මාරු කළ හැකිය, නැතහොත් අපට බාහිර අන්තර්ක්‍රියා සීමා කර පොකුරේ සිට සියලු සංචාර පාලනය කළ හැකිය. බාහිර ජාලය. විවිධ ක්ෂුද්‍ර සේවා අතර සංචාර පාලනය කිරීමට ප්‍රතිපත්ති රීති සැකසීමට හැකිය. අවසාන වශයෙන්, අපට සම්පූර්ණ ජාල අන්තර්ක්‍රියා සිතියම ලබා ගත හැකි අතර ඒකාබද්ධ ප්‍රමිතික එකතුව යෙදුම්වලට සම්පූර්ණයෙන්ම විනිවිද පෙනෙන බවට පත් කළ හැකිය.

වැඩ කිරීමේ යාන්ත්රණය ගැන ඔබට කියවිය හැකිය නිල ලියකියවිලි. Istio යනු බොහෝ කාර්යයන් සහ ගැටළු විසඳීමට ඔබට ඉඩ සලසන සැබවින්ම බලවත් මෙවලමකි. මෙම ලිපියෙන්, Istio සමඟ ආරම්භ කිරීමේදී සාමාන්යයෙන් පැන නගින ප්රධාන ප්රශ්නවලට පිළිතුරු දීමට මම කැමතියි. මෙය ඔබට එය සමඟ වේගයෙන් කටයුතු කිරීමට උපකාරී වනු ඇත.

එය ක්රියා කරන ආකාරය

Istio ප්‍රධාන අංශ දෙකකින් සමන්විත වේ - පාලන තලය සහ දත්ත තලය. පාලක තලය ඉතිරිව ඇති නිවැරදි ක්රියාකාරීත්වය සහතික කරන ප්රධාන සංරචක අඩංගු වේ. වත්මන් අනුවාදයේ (1.0) පාලන තලය ප්රධාන සංරචක තුනක් ඇත: නියමු, මික්සර්, Citadel. අපි Citadel සලකා බලන්නේ නැත, සේවා අතර අන්‍යෝන්‍ය TLS සහතික කිරීම සඳහා සහතික උත්පාදනය කිරීම අවශ්‍ය වේ. Pilot සහ Mixer හි උපාංගය සහ අරමුණ දෙස සමීපව බලමු.

පයිලට් යනු පොකුරේ අප සතුව ඇති දේ - සේවා, ඒවායේ අවසාන ලක්ෂ්‍ය සහ මාර්ගගත කිරීමේ නීති (උදාහරණයක් ලෙස, කැනරි යෙදවීමේ නීති හෝ පරිපථ කඩන රීති) පිළිබඳ සියලු තොරතුරු බෙදා හරින ප්‍රධාන පාලන සංරචකයයි.

මික්සර් යනු ප්‍රමිතික, ලඝු-සටහන් සහ ජාල අන්තර්ක්‍රියා පිළිබඳ ඕනෑම තොරතුරක් එකතු කිරීමේ හැකියාව සපයන විකල්ප පාලන තල සංරචකයකි. ඔහු ප්‍රතිපත්ති රීතිවලට අනුකූල වීම සහ අනුපාත සීමාවන්ට අනුකූල වීම ද නිරීක්ෂණය කරයි.

දත්ත තලය සයිඩ්කාර් ප්‍රොක්සි බහාලුම් භාවිතයෙන් ක්‍රියාත්මක වේ. බලවත් යනු පෙරනිමියෙන් භාවිතා වේ. නියෝජිත ප්‍රොක්සි. එය nginx (nginmesh) වැනි වෙනත් ක්‍රියාත්මක කිරීමකින් ප්‍රතිස්ථාපනය කළ හැක.

Istio යෙදුම් සඳහා සම්පූර්ණයෙන්ම විනිවිද පෙනෙන ලෙස ක්රියා කිරීම සඳහා, ස්වයංක්රීය එන්නත් පද්ධතියක් ඇත. නවතම ක්‍රියාත්මක කිරීම Kubernetes 1.9+ අනුවාද සඳහා සුදුසු වේ (mutational admission webhook). Kubernetes අනුවාද 1.7, 1.8 සඳහා Initializer භාවිතා කළ හැක.

පැති කාර් බහාලුම් GRPC ප්‍රොටෝකෝලය භාවිතයෙන් නියමු වෙත සම්බන්ධ කර ඇති අතර එමඟින් පොකුරේ සිදුවන වෙනස්කම් සඳහා තල්ලු ආකෘතිය ප්‍රශස්ත කිරීමට ඔබට ඉඩ සලසයි. GRPC Envoy හි 1.6 අනුවාදයේ සිට භාවිතා කර ඇත, Istio හි එය 0.8 අනුවාදයේ සිට භාවිතා කර ඇති අතර එය නියමු-නියෝජිතයෙකු වේ - දියත් කිරීමේ විකල්පයන් වින්‍යාස කරන එන්වෝයි හරහා ගෝලාං දවටනයකි.

නියමු සහ මික්සර් සම්පූර්ණයෙන්ම අස්ථායී සංරචක වේ, සියලු තත්වය මතකයේ තබා ඇත. ඒවා සඳහා වින්‍යාසය ආදියෙහි ගබඩා කර ඇති Kubernetes Custom Resources ආකාරයෙන් සකසා ඇත.
Istio-agent නියමුවාගේ ලිපිනය ලබාගෙන එයට GRPC ප්‍රවාහයක් විවෘත කරයි.

මම කී පරිදි, Istio සියලුම ක්‍රියාකාරීත්වය යෙදුම් වලට සම්පූර්ණයෙන්ම විනිවිද පෙනෙන ලෙස ක්‍රියාත්මක කරයි. අපි බලමු කොහොමද කියලා. ඇල්ගොරිතම මෙයයි:

1. සේවාවේ නව අනුවාදයක් යෙදවීම.
2. සයිඩ්කාර් බහාලුම් එන්නත් කිරීමේ ප්‍රවේශය මත පදනම්ව, වින්‍යාසය යොදන අවස්ථාවේදී istio-init කන්ටේනරය සහ istio-ඒජන්ත බහාලුම් (දූතයා) එකතු කරනු ලැබේ, නැතහොත් ඒවා දැනටමත් Kubernetes Pod ආයතනයේ විස්තරයට අතින් ඇතුළු කළ හැකිය.
3. istio-init කන්ටේනරය යනු iptables රීති පොඩ් එකට යොදන ස්ක්‍රිප්ට් එකකි. istio-agent කන්ටේනරයක ඔතා ගමනාගමනය වින්‍යාස කිරීම සඳහා විකල්ප දෙකක් තිබේ: iptables යළි-යොමුවීම් නීති භාවිතා කරන්න, හෝ TPROXY. ලියන අවස්ථාවේදී, පෙරනිමි ප්‍රවේශය යළි-යොමුවීම් නීති සමඟ වේ. istio-init හි, කුමන ගමනාගමනයට බාධා කළ යුතුද සහ istio-agent වෙත යැවිය යුතුද යන්න වින්‍යාසගත කළ හැක. උදාහරණයක් ලෙස, සියලුම පැමිණෙන සහ පිටතට යන ගමනාගමනය බාධා කිරීම සඳහා, ඔබ පරාමිති සැකසීමට අවශ්ය වේ -i и -b අර්ථයට *. ඔබට බාධා කිරීමට නිශ්චිත වරායන් සඳහන් කළ හැක. නිශ්චිත උපජාලයකට බාධා නොකිරීමට, ඔබට එය ධජය භාවිතයෙන් නියම කළ හැක -x.
4. init බහාලුම් ක්‍රියාත්මක කිරීමෙන් පසුව, නියමු නියෝජිතයා (දූතයා) ඇතුළුව ප්‍රධාන ඒවා දියත් කරනු ලැබේ. එය GRPC හරහා දැනටමත් යොදවා ඇති නියමු වෙත සම්බන්ධ වන අතර පොකුරේ පවතින සියලුම සේවා සහ මාර්ගගත කිරීමේ ප්‍රතිපත්ති පිළිබඳ තොරතුරු ලබා ගනී. ලැබුණු දත්ත වලට අනුව, ඔහු පොකුරු වින්‍යාස කර ඒවා කෙලින්ම Kubernetes පොකුරේ අපගේ යෙදුම්වල අවසාන ලක්ෂ්‍ය වෙත පවරයි. වැදගත් කරුණක් සටහන් කිරීම ද අවශ්‍ය වේ: එන්වොයි එය සවන් දීමට පටන් ගන්නා සවන්දෙන්නන් (IP, වරාය යුගල) ගතිකව වින්‍යාස කරයි. එබැවින්, ඉල්ලීම් පෝඩ් එකට ඇතුළු වූ විට, සයිඩ්කාර් තුළ ඇති යළි-යොමුවීම් iptables රීති භාවිතයෙන් යළි හරවා යවනු ලබන විට, නියෝජිතයාට දැනටමත් මෙම සම්බන්ධතා සාර්ථකව ක්‍රියාකරවීමට සහ ගමනාගමනය තවදුරටත් ප්‍රොක්සි කළ යුත්තේ කොතැනද යන්න තේරුම් ගත හැකිය. මෙම අවස්ථාවෙහිදී, තොරතුරු මික්සර් වෙත යවනු ලැබේ, එය අපි පසුව බලමු, සහ ලුහුබැඳීමේ පරතරය යවනු ලැබේ.

එහි ප්‍රතිඵලයක් වශයෙන්, අපට එක් ලක්ෂ්‍යයකින් (පයිලට්) වින්‍යාසගත කළ හැකි එන්වෝයි ප්‍රොක්සි සර්වර් ජාලයක් අපට ලැබේ. පැමිණෙන සහ පිටතට යන සියලුම ඉල්ලීම් නියෝජිතයන් හරහා සිදු වේ. එපමණක් නොව, TCP ගමනාගමනය පමණක් බාධා වේ. මෙයින් අදහස් කරන්නේ Kubernetes සේවා IP වෙනස් නොකර UDP හරහා kube-dns භාවිතයෙන් විසඳන බවයි. පසුව, නිරාකරණයෙන් පසුව, පිටත්ව යන ඉල්ලීම නියෝජිතයා විසින් බාධා කර සකසනු ලබන අතර, ඉල්ලීම යැවිය යුත්තේ කුමන අන්ත ලක්ෂ්‍යයටද යන්න දැනටමත් තීරණය කරයි (නැතහොත්, ප්‍රවේශ ප්‍රතිපත්ති හෝ ඇල්ගොරිතමයේ පරිපථ කඩනය සම්බන්ධයෙන්) ය.

අපි නියමුවා හඳුනා ගත්තා, දැන් අපි මික්සර් ක්‍රියා කරන ආකාරය සහ එය අවශ්‍ය වන්නේ මන්දැයි තේරුම් ගත යුතුය. ඔබට ඒ සඳහා නිල ලියකියවිලි කියවිය හැකිය මෙහි.

එහි වත්මන් ස්වරූපයෙන් මික්සර් සංරචක දෙකකින් සමන්විත වේ: istio-telemetry, istio-policy (0.8 අනුවාදයට පෙර එය එක් istio-මික්සර් සංරචකයක් විය). ඔවුන් දෙදෙනාම මිශ්ර කරන්නන් වන අතර, ඒ සෑම එකක්ම තමන්ගේම කාර්යය සඳහා වගකිව යුතුය. ජීආර්පීසී හරහා සයිඩ්කාර් වාර්තා කන්ටේනර් වලින් යන්නේ කවුද සහ කුමන පරාමිතීන් සමඟද යන්න පිළිබඳ තොරතුරු ඉස්ටියෝ ටෙලිමෙට්‍රි වෙත ලැබේ. Istio-policy ප්‍රතිපත්ති රීති තෘප්තිමත් බව තහවුරු කිරීම සඳහා චෙක් ඉල්ලීම් පිළිගනී. ප්‍රතිපත්ති පිරික්සුම්, ඇත්ත වශයෙන්ම, සෑම ඉල්ලීමක් සඳහාම සිදු නොකෙරේ, නමුත් යම් කාලයක් සඳහා සේවාලාභියා (සයිඩ්කාර් තුළ) හැඹිලිගත කරනු ලැබේ. වාර්තා චෙක්පත් කණ්ඩායම් ඉල්ලීම් ලෙස යවනු ලැබේ. වින්‍යාස කරන්නේ කෙසේද සහ මඳ වේලාවකට පසුව යැවිය යුතු පරාමිති මොනවාදැයි බලමු.

මික්සර් යනු ටෙලිමෙට්‍රි දත්ත එකලස් කිරීමේ සහ සැකසීමේ බාධාවකින් තොරව වැඩ කිරීම සහතික කරන ඉතා ඉහළ මට්ටමක පවතින සංරචකයක් විය යුතුය. පද්ධතිය බහු මට්ටමේ බෆරයක් ලෙස ප්රතිඵලයක් ලෙස ලබා ගනී. මුලදී, දත්ත බහාලුම්වල සයිඩ්කාර් පැත්තේ, පසුව මික්සර් පැත්තේ, පසුව ඊනියා මික්සර් පසුපෙළ වෙත යවනු ලැබේ. එහි ප්රතිඵලයක් වශයෙන්, පද්ධතියේ සංරචක කිසිවක් අසමත් වුවහොත්, බෆරය වර්ධනය වන අතර පද්ධතිය ප්රතිෂ්ඨාපනය කිරීමෙන් පසුව එය සෝදා හරිනු ලැබේ. මික්සර් පසුබිම් යනු දුරස්ථ දත්ත යැවීම සඳහා වන අන්ත ලක්ෂ්‍ය වේ: statsd, newrelic, ආදිය. ඔබට ඔබේම පසුබිමක් ලිවිය හැකිය, එය ඉතා සරල ය, අපි එය කරන්නේ කෙසේදැයි බලමු.

සාරාංශ කිරීම සඳහා, istio-telemetry සමඟ වැඩ කිරීමේ යෝජනා ක්රමය පහත පරිදි වේ.

1. සේවා 1 සේවාව 2 වෙත ඉල්ලීමක් යවයි.
2. සේවා 1 හැර යන විට, ඉල්ලීම එහිම පැති රථයේ ඔතා ඇත.
3. Sidecar නියෝජිතයා ඉල්ලීම සේවාව 2 වෙත යන ආකාරය නිරීක්ෂණය කරන අතර අවශ්‍ය තොරතුරු සකස් කරයි.
4. ඉන්පසුව Report ඉල්ලීමක් භාවිතයෙන් එය istio-telemetry වෙත යවයි.
5. Istio-telemetry විසින් මෙම වාර්තාව යැවිය යුත්තේ පසුපෙළ වෙතද, කුමන දත්ත වෙත යැවිය යුතුද යන්න තීරණය කරයි.
6. Istio-telemetry අවශ්‍ය නම් වාර්තා දත්ත පසු අන්තයට යවයි.

දැන් අපි බලමු ප්‍රධාන කොටස් වලින් (Pilot and sidecar envoy) පමණක් සමන්විත පද්ධතිය තුල Istio යෙදවිය යුතු ආකාරය.

පළමුව, නියමු කියවන ප්‍රධාන වින්‍යාසය (දැල) දෙස බලමු:

apiVersion: v1
kind: ConfigMap
metadata:
  name: istio
  namespace: istio-system
  labels:
    app: istio
    service: istio
data:
  mesh: |-

    # пока что не включаем отправку tracing информации (pilot настроит envoy’и таким образом, что отправка не будет происходить)
    enableTracing: false

    # пока что не указываем mixer endpoint’ы, чтобы sidecar контейнеры не отправляли информацию туда
    #mixerCheckServer: istio-policy.istio-system:15004
    #mixerReportServer: istio-telemetry.istio-system:15004

    # ставим временной промежуток, с которым будет envoy переспрашивать Pilot (это для старой версии envoy proxy)
    rdsRefreshDelay: 5s

    # default конфигурация для envoy sidecar
    defaultConfig:
      # аналогично как rdsRefreshDelay
      discoveryRefreshDelay: 5s

      # оставляем по умолчанию (путь к конфигурации и бинарю envoy)
      configPath: "/etc/istio/proxy"
      binaryPath: "/usr/local/bin/envoy"

      # дефолтное имя запущенного sidecar контейнера (используется, например, в именах сервиса при отправке tracing span’ов)
      serviceCluster: istio-proxy

      # время, которое будет ждать envoy до того, как он принудительно завершит все установленные соединения
      drainDuration: 45s
      parentShutdownDuration: 1m0s

      # по умолчанию используются REDIRECT правила iptables. Можно изменить на TPROXY.
      #interceptionMode: REDIRECT

      # Порт, на котором будет запущена admin панель каждого sidecar контейнера (envoy)
      proxyAdminPort: 15000

      # адрес, по которому будут отправляться trace’ы по zipkin протоколу (в начале мы отключили саму отправку, поэтому это поле сейчас не будет использоваться)
      zipkinAddress: tracing-collector.tracing:9411

      # statsd адрес для отправки метрик envoy контейнеров (отключаем)
      # statsdUdpAddress: aggregator:8126

      # выключаем поддержку опции Mutual TLS
      controlPlaneAuthPolicy: NONE

      # адрес, на котором будет слушать istio-pilot для того, чтобы сообщать информацию о service discovery всем sidecar контейнерам
      discoveryAddress: istio-pilot.istio-system:15007

සියලුම ප්‍රධාන පාලන සංරචක (පාලන තලය) Kubernetes හි ඇති namespace istio-system හි පිහිටා ඇත.

අවම වශයෙන්, අපට අවශ්‍ය වන්නේ නියමුවෙකු යෙදවීමට පමණි. මේ සඳහා අපි භාවිතා කරන්නෙමු එවැනි වින්යාසයක්.

තවද අපි කන්ටේනරයේ එන්නත් කරන පැති කාර් එක අතින් වින්‍යාස කරන්නෙමු.

ආරම්භක බහාලුම්:

initContainers:
 - name: istio-init
   args:
   - -p
   - "15001"
   - -u
   - "1337"
   - -m
   - REDIRECT
   - -i
   - '*'
   - -b
   - '*'
   - -d
   - ""
   image: istio/proxy_init:1.0.0
   imagePullPolicy: IfNotPresent
   resources:
     limits:
       memory: 128Mi
   securityContext:
     capabilities:
       add:
       - NET_ADMIN

සහ පැති කාර්:

       name: istio-proxy
       args:
         - "bash"
         - "-c"
         - |
           exec /usr/local/bin/pilot-agent proxy sidecar 
           --configPath 
           /etc/istio/proxy 
           --binaryPath 
           /usr/local/bin/envoy 
           --serviceCluster 
           service-name 
           --drainDuration 
           45s 
           --parentShutdownDuration 
           1m0s 
           --discoveryAddress 
           istio-pilot.istio-system:15007 
           --discoveryRefreshDelay 
           1s 
           --connectTimeout 
           10s 
           --proxyAdminPort 
           "15000" 
           --controlPlaneAuthPolicy 
           NONE
         env:
         - name: POD_NAME
           valueFrom:
             fieldRef:
               fieldPath: metadata.name
         - name: POD_NAMESPACE
           valueFrom:
             fieldRef:
               fieldPath: metadata.namespace
         - name: INSTANCE_IP
           valueFrom:
             fieldRef:
               fieldPath: status.podIP
         - name: ISTIO_META_POD_NAME
           valueFrom:
             fieldRef:
               fieldPath: metadata.name
         - name: ISTIO_META_INTERCEPTION_MODE
           value: REDIRECT
         image: istio/proxyv2:1.0.0
         imagePullPolicy: IfNotPresent
         resources:
           requests:
             cpu: 100m
             memory: 128Mi
           limits:
             memory: 2048Mi
         securityContext:
           privileged: false
           readOnlyRootFilesystem: true
           runAsUser: 1337
         volumeMounts:
         - mountPath: /etc/istio/proxy
           name: istio-envoy

සෑම දෙයක්ම සාර්ථකව ආරම්භ කිරීම සඳහා, ඔබ විසින් ServiceAccount, ClusterRole, ClusterRoleBinding, CRD සඳහා නියමු, විස්තර සොයා ගත හැකි නිර්මාණය කළ යුතුය. මෙහි.

එහි ප්‍රතිඵලයක් වශයෙන්, අප දූතයා සමඟ පැති කාර් එන්නත් කරන සේවාව සාර්ථකව ආරම්භ කළ යුතු අතර, නියමුවාගෙන් සියලු සොයාගැනීම් ලබාගෙන ඉල්ලීම් ක්‍රියාවට නැංවිය යුතුය.

සියලුම පාලන තල සංරචක අස්ථායී යෙදුම් වන අතර ගැටළු නොමැතිව තිරස් ලෙස පරිමාණය කළ හැකි බව වටහා ගැනීම වැදගත්ය. සියලු දත්ත Kubernetes සම්පත් අභිරුචි විස්තර ආකාරයෙන් etcd ගබඩා කර ඇත.

එසේම, Istio (තවමත් පර්යේෂණාත්මක) පොකුරෙන් පිටත ධාවනය කිරීමේ හැකියාව සහ Kubernetes පොකුරු කිහිපයක් අතර සේවා සොයාගැනීම් නැරඹීමට සහ බාධා කිරීමේ හැකියාව ඇත. ඔබට මේ ගැන වැඩිදුර කියවිය හැකිය මෙහි.

බහු-පොකුරු ස්ථාපනය සඳහා, පහත සීමාවන් පිළිබඳව දැනුවත් වන්න:

1. Pod CIDR සහ Service CIDR සියලුම පොකුරු හරහා අනන්‍ය විය යුතු අතර අතිච්ඡාදනය නොවිය යුතුය.
2. සියලුම CIDR Pods පොකුරු අතර ඇති ඕනෑම CIDR Pods එකකින් ප්‍රවේශ විය යුතුය.
3. සියලුම Kubernetes API සේවාදායකයන් එකිනෙකට ප්‍රවේශ විය යුතුය.

Istio සමඟ ආරම්භ කිරීමට ඔබට උපකාර වන මූලික තොරතුරු මෙයයි. කෙසේ වෙතත්, තවමත් බොහෝ උගුල් තිබේ. උදාහරණයක් ලෙස, බාහිර ගමනාගමනය (පොකුරෙන් පිටත) මාර්ගගත කිරීමේ විශේෂාංග, පැතිකාර් නිදොස් කිරීම සඳහා ප්‍රවේශයන්, පැතිකඩ කිරීම, මික්සර් සැකසීම සහ අභිරුචි මිශ්‍ර පසුබිමක් ලිවීම, ලුහුබැඳීමේ යාන්ත්‍රණයක් සැකසීම සහ නියෝජිතයා භාවිතයෙන් එහි ක්‍රියාකාරිත්වය.
මේ සියල්ල අපි පහත ප්‍රකාශනවල සලකා බලමු. ඔබේ ප්‍රශ්න අසන්න, මම ඒවා ආවරණය කිරීමට උත්සාහ කරමි.

මූලාශ්රය: www.habr.com