ઉત્પાદનમાં કુબરનેટ્સનો ઉપયોગ કરીને Istio કેવી રીતે ચલાવવું. ભાગ 1

શું ઇસ્ટિઓ? આ કહેવાતા સર્વિસ મેશ છે, એક એવી તકનીક જે નેટવર્ક પર અમૂર્તતાનું સ્તર ઉમેરે છે. અમે ક્લસ્ટરમાંના તમામ અથવા અમુક ટ્રાફિકને અટકાવીએ છીએ અને તેની સાથે ચોક્કસ સેટ ઑપરેશન કરીએ છીએ. કયો? ઉદાહરણ તરીકે, અમે સ્માર્ટ રૂટીંગ કરીએ છીએ, અથવા અમે સર્કિટ બ્રેકર અભિગમનો અમલ કરીએ છીએ, અમે "કેનેરી ડિપ્લોયમેન્ટ" ગોઠવી શકીએ છીએ, ટ્રાફિકને આંશિક રીતે સેવાના નવા સંસ્કરણ પર સ્વિચ કરી શકીએ છીએ, અથવા અમે બાહ્ય ક્રિયાપ્રતિક્રિયાઓને મર્યાદિત કરી શકીએ છીએ અને ક્લસ્ટરથી તમામ ટ્રિપ્સને નિયંત્રિત કરી શકીએ છીએ. બાહ્ય નેટવર્ક. વિવિધ માઇક્રોસેવાઓ વચ્ચેની ટ્રિપ્સને નિયંત્રિત કરવા માટે નીતિ નિયમો સેટ કરવાનું શક્ય છે. અંતે, અમે સમગ્ર નેટવર્ક ક્રિયાપ્રતિક્રિયાનો નકશો મેળવી શકીએ છીએ અને મેટ્રિક્સના એકીકૃત સંગ્રહને એપ્લિકેશન્સ માટે સંપૂર્ણપણે પારદર્શક બનાવી શકીએ છીએ.

માં કામ કરવાની પદ્ધતિ વિશે તમે વાંચી શકો છો સત્તાવાર દસ્તાવેજીકરણ. Istio એ ખરેખર શક્તિશાળી સાધન છે જે તમને ઘણા કાર્યો અને સમસ્યાઓ હલ કરવા દે છે. આ લેખમાં, હું ઇસ્ટિઓ સાથે પ્રારંભ કરતી વખતે સામાન્ય રીતે ઉદ્ભવતા મુખ્ય પ્રશ્નોના જવાબ આપવા માંગુ છું. આ તમને તેની સાથે ઝડપથી વ્યવહાર કરવામાં મદદ કરશે.

તે કેવી રીતે કામ કરે છે

Istio બે મુખ્ય ક્ષેત્રો ધરાવે છે - નિયંત્રણ પ્લેન અને ડેટા પ્લેન. કંટ્રોલ પ્લેનમાં મુખ્ય ઘટકો શામેલ છે જે બાકીના યોગ્ય સંચાલનને સુનિશ્ચિત કરે છે. વર્તમાન સંસ્કરણ (1.0) માં કંટ્રોલ પ્લેનમાં ત્રણ મુખ્ય ઘટકો છે: પાયલટ, મિક્સર, સિટાડેલ. અમે સિટાડેલને ધ્યાનમાં લઈશું નહીં, સેવાઓ વચ્ચે પરસ્પર TLS સુનિશ્ચિત કરવા માટે પ્રમાણપત્રો જનરેટ કરવા જરૂરી છે. ચાલો પાયલોટ અને મિક્સરના ઉપકરણ અને હેતુ પર નજીકથી નજર કરીએ.

પાયલોટ એ મુખ્ય નિયંત્રણ ઘટક છે જે ક્લસ્ટરમાં અમારી પાસે શું છે તે વિશેની તમામ માહિતીનું વિતરણ કરે છે - સેવાઓ, તેમના અંતિમ બિંદુઓ અને રૂટીંગ નિયમો (ઉદાહરણ તરીકે, કેનેરી ડિપ્લોયમેન્ટ અથવા સર્કિટ બ્રેકરના નિયમો).

મિક્સર એ વૈકલ્પિક નિયંત્રણ પ્લેન ઘટક છે જે મેટ્રિક્સ, લોગ્સ અને નેટવર્ક ક્રિયાપ્રતિક્રિયા વિશેની કોઈપણ માહિતી એકત્રિત કરવાની ક્ષમતા પ્રદાન કરે છે. તે નીતિ નિયમોના પાલન અને દર મર્યાદાઓનું પાલન પણ મોનિટર કરે છે.

ડેટા પ્લેન સાઇડકાર પ્રોક્સી કન્ટેનરનો ઉપયોગ કરીને લાગુ કરવામાં આવે છે. પાવરફુલનો ઉપયોગ મૂળભૂત રીતે થાય છે. રાજદૂત પ્રોક્સી. તેને અન્ય અમલીકરણ દ્વારા બદલી શકાય છે, જેમ કે nginx (nginmesh).

Istio એપ્લીકેશનમાં સંપૂર્ણપણે પારદર્શક રીતે કામ કરે તે માટે, ત્યાં ઓટોમેટિક ઈન્જેક્શન સિસ્ટમ છે. નવીનતમ અમલીકરણ Kubernetes 1.9+ સંસ્કરણો (મ્યુટેશનલ એડમિશન વેબહૂક) માટે યોગ્ય છે. કુબરનેટ્સ વર્ઝન 1.7, 1.8 માટે ઇનિશિયલાઈઝરનો ઉપયોગ શક્ય છે.

સાઇડકાર કન્ટેનર GRPC પ્રોટોકોલનો ઉપયોગ કરીને પાયલોટ સાથે જોડાયેલા છે, જે તમને ક્લસ્ટરમાં થતા ફેરફારો માટે પુશ મોડલને ઑપ્ટિમાઇઝ કરવાની મંજૂરી આપે છે. GRPC એ એન્વોયમાં વર્ઝન 1.6 થી ઉપયોગમાં લેવાય છે, Istio માં તેનો ઉપયોગ વર્ઝન 0.8 થી થાય છે અને તે પાઇલોટ-એજન્ટ છે - એન્વોય પર ગોલાંગ રેપર જે લોન્ચ વિકલ્પોને ગોઠવે છે.

પાયલોટ અને મિક્સર સંપૂર્ણપણે સ્ટેટલેસ ઘટકો છે, તમામ સ્થિતિ મેમરીમાં રાખવામાં આવે છે. તેમના માટેનું રૂપરેખાંકન કુબરનેટ્સ કસ્ટમ રિસોર્સિસના સ્વરૂપમાં સેટ કરવામાં આવ્યું છે, જે વગેરે વગેરેમાં સંગ્રહિત છે.
Istio-એજન્ટ પાયલટનું સરનામું મેળવે છે અને તેના માટે GRPC સ્ટ્રીમ ખોલે છે.

મેં કહ્યું તેમ, Istio એપ્લીકેશન માટે સંપૂર્ણપણે પારદર્શક તમામ કાર્યક્ષમતા લાગુ કરે છે. ચાલો જોઈએ કેવી રીતે. અલ્ગોરિધમ આ છે:

1. સેવાના નવા સંસ્કરણનો ઉપયોગ કરી રહ્યાં છીએ.
2. સાઇડકાર કન્ટેનર ઇન્જેક્શન અભિગમ પર આધાર રાખીને, ઇસ્ટિઓ-ઇનિટ કન્ટેનર અને ઇસ્ટિઓ-એજન્ટ કન્ટેનર (દૂત) રૂપરેખાંકન લાગુ કરવાના તબક્કે ઉમેરવામાં આવે છે, અથવા તેઓ કુબરનેટ્સ પોડ એન્ટિટીના વર્ણનમાં પહેલેથી જ મેન્યુઅલી દાખલ કરી શકાય છે.
3. istio-init કન્ટેનર એ એક સ્ક્રિપ્ટ છે જે પોડ પર iptables નિયમો લાગુ કરે છે. ઇસ્ટિઓ-એજન્ટ કન્ટેનરમાં આવરિત થવા માટે ટ્રાફિકને ગોઠવવા માટેના બે વિકલ્પો છે: iptables રીડાયરેક્ટ નિયમોનો ઉપયોગ કરો, અથવા TPROXY. લેખન સમયે, ડિફૉલ્ટ અભિગમ રીડાયરેક્ટ નિયમો સાથે છે. istio-init માં, કયા ટ્રાફિકને અટકાવવો જોઈએ અને istio-એજન્ટને મોકલવો જોઈએ તે ગોઠવવું શક્ય છે. ઉદાહરણ તરીકે, તમામ ઇનકમિંગ અને તમામ આઉટગોઇંગ ટ્રાફિકને અટકાવવા માટે, તમારે પરિમાણો સેટ કરવાની જરૂર છે -i и -b અર્થમાં *. તમે અટકાવવા માટે ચોક્કસ પોર્ટનો ઉલ્લેખ કરી શકો છો. ચોક્કસ સબનેટને અટકાવવા માટે, તમે ધ્વજનો ઉપયોગ કરીને તેનો ઉલ્લેખ કરી શકો છો -x.
4. ઇનિટ કન્ટેનર ચલાવવામાં આવે તે પછી, પાઇલટ-એજન્ટ (દૂત) સહિત મુખ્ય લોંચ કરવામાં આવે છે. તે GRPC મારફતે પહેલેથી જ તૈનાત પાઇલટ સાથે જોડાય છે અને ક્લસ્ટરમાં તમામ વર્તમાન સેવાઓ અને રૂટીંગ નીતિઓ વિશે માહિતી મેળવે છે. પ્રાપ્ત માહિતી અનુસાર, તે ક્લસ્ટરોને રૂપરેખાંકિત કરે છે અને કુબરનેટ્સ ક્લસ્ટરમાં અમારી એપ્લિકેશનના અંતિમ બિંદુઓને સીધા જ સોંપે છે. એક મહત્વપૂર્ણ મુદ્દાની નોંધ લેવી પણ જરૂરી છે: દૂત શ્રોતાઓને ગતિશીલ રીતે ગોઠવે છે (IP, પોર્ટ જોડી) જે તે સાંભળવાનું શરૂ કરે છે. તેથી, જ્યારે વિનંતીઓ પોડમાં દાખલ થાય છે, ત્યારે સાઇડકારમાં રીડાયરેક્ટ iptables નિયમોનો ઉપયોગ કરીને રીડાયરેક્ટ કરવામાં આવે છે, ત્યારે રાજદૂત પહેલેથી જ સફળતાપૂર્વક આ જોડાણો પર પ્રક્રિયા કરી શકે છે અને ટ્રાફિકને આગળ પ્રોક્સી ક્યાં કરવી તે સમજી શકે છે. આ તબક્કે, માહિતી મિક્સરને મોકલવામાં આવે છે, જે આપણે પછીથી જોઈશું, અને ટ્રેસિંગ સ્પાન્સ મોકલવામાં આવે છે.

પરિણામે, અમને દૂત પ્રોક્સી સર્વર્સનું આખું નેટવર્ક મળે છે જેને અમે એક બિંદુ (પાયલોટ) થી ગોઠવી શકીએ છીએ. તમામ ઈનબાઉન્ડ અને આઉટબાઉન્ડ વિનંતીઓ રાજદૂત મારફતે જાય છે. તદુપરાંત, ફક્ત TCP ટ્રાફિકને અટકાવવામાં આવે છે. આનો અર્થ એ છે કે Kubernetes સેવા IP ને બદલ્યા વિના UDP પર kube-dns નો ઉપયોગ કરીને ઉકેલવામાં આવે છે. પછી, નિરાકરણ પછી, દૂત દ્વારા આઉટગોઇંગ વિનંતીને અટકાવવામાં આવે છે અને પ્રક્રિયા કરવામાં આવે છે, જે પહેલાથી જ નક્કી કરે છે કે વિનંતી કયા એન્ડપોઇન્ટને મોકલવી જોઈએ (અથવા મોકલવામાં નહીં આવે, એક્સેસ પોલિસી અથવા અલ્ગોરિધમના સર્કિટ બ્રેકરના કિસ્સામાં).

અમે પાઇલટને શોધી કાઢ્યું, હવે આપણે સમજવાની જરૂર છે કે મિક્સર કેવી રીતે કાર્ય કરે છે અને શા માટે તેની જરૂર છે. તમે તેના માટે સત્તાવાર દસ્તાવેજો વાંચી શકો છો અહીં.

તેના વર્તમાન સ્વરૂપમાં મિક્સરમાં બે ઘટકોનો સમાવેશ થાય છે: ઇસ્ટિઓ-ટેલિમેટ્રી, ઇસ્ટિઓ-પોલીસી (સંસ્કરણ 0.8 પહેલાં તે એક ઇસ્ટિઓ-મિક્સર ઘટક હતું). તે બંને મિક્સર છે, જેમાંથી દરેક તેના પોતાના કાર્ય માટે જવાબદાર છે. Istio ટેલિમેટ્રી GRPC મારફતે સાઇડકાર રિપોર્ટ કન્ટેનરમાંથી કોણ ક્યાં અને કયા પરિમાણો સાથે જાય છે તેની માહિતી મેળવે છે. Istio-policy નીતિ નિયમો સંતુષ્ટ છે તે ચકાસવા માટે ચેક વિનંતીઓ સ્વીકારે છે. પૉલિસી ચેક, અલબત્ત, દરેક વિનંતી માટે હાથ ધરવામાં આવતાં નથી, પરંતુ ચોક્કસ સમય માટે ક્લાયન્ટ (સાઇડકારમાં) પર કૅશ કરવામાં આવે છે. રિપોર્ટ ચેક બેચ વિનંતીઓ તરીકે મોકલવામાં આવે છે. ચાલો જોઈએ કે કેવી રીતે ગોઠવવું અને કયા પરિમાણો થોડા સમય પછી મોકલવા જોઈએ.

મિક્સર એ અત્યંત ઉપલબ્ધ ઘટક હોવાનું માનવામાં આવે છે જે ટેલિમેટ્રી ડેટાની એસેમ્બલી અને પ્રોસેસિંગ પર અવિરત કાર્ય સુનિશ્ચિત કરે છે. મલ્ટિ-લેવલ બફરના પરિણામે સિસ્ટમ પ્રાપ્ત થાય છે. શરૂઆતમાં, ડેટાને કન્ટેનરની સાઇડકાર બાજુ પર બફર કરવામાં આવે છે, પછી મિક્સર બાજુ પર, અને પછી કહેવાતા મિક્સર બેકએન્ડ પર મોકલવામાં આવે છે. પરિણામે, જો સિસ્ટમના કોઈપણ ઘટકો નિષ્ફળ જાય, તો બફર વધે છે અને સિસ્ટમ પુનઃસ્થાપિત થયા પછી ફ્લશ થાય છે. મિક્સર બેકએન્ડ એ ટેલિમેટ્રી ડેટા મોકલવા માટેના અંતિમ બિંદુઓ છે: statsd, newrelic, વગેરે. તમે તમારું પોતાનું બેકએન્ડ લખી શકો છો, તે એકદમ સરળ છે, અને અમે તે કેવી રીતે કરવું તે જોઈશું.

સારાંશ માટે, ઇસ્ટિઓ-ટેલિમેટ્રી સાથે કામ કરવાની યોજના નીચે મુજબ છે.

1. સેવા 1 સેવા 2 ને વિનંતી મોકલે છે.
2. સેવા 1 છોડતી વખતે, વિનંતી તેની પોતાની સાઇડકારમાં લપેટી છે.
3. સાઇડકાર દૂત મોનિટર કરે છે કે કેવી રીતે વિનંતી સેવા 2 પર જાય છે અને જરૂરી માહિતી તૈયાર કરે છે.
4. પછી રિપોર્ટ વિનંતીનો ઉપયોગ કરીને તેને istio-telemetry પર મોકલે છે.
5. Istio-telemetry નક્કી કરે છે કે શું આ રિપોર્ટ બેકએન્ડ પર મોકલવો જોઈએ, કયો અને કયો ડેટા મોકલવો જોઈએ.
6. Istio-telemetry જો જરૂરી હોય તો બેકએન્ડ પર રિપોર્ટ ડેટા મોકલે છે.

હવે ચાલો જોઈએ કે સિસ્ટમમાં 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

બધા મુખ્ય નિયંત્રણ ઘટકો (કંટ્રોલ પ્લેન) કુબરનેટ્સમાં નેમસ્પેસ ઇસ્ટિઓ-સિસ્ટમમાં સ્થિત હશે.

ઓછામાં ઓછા, અમારે માત્ર પાઈલટને તૈનાત કરવાની જરૂર છે. આ માટે આપણે ઉપયોગ કરીશું આવી રૂપરેખાંકન.

અને અમે કન્ટેનરની ઇન્જેક્શન સાઇડકારને મેન્યુઅલી ગોઠવીશું.

ઇનિટ કન્ટેનર:

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 બનાવવાની જરૂર છે, જેનું વર્ણન મળી શકે છે. અહીં.

પરિણામે, અમે જે સેવામાં દૂત સાથે સાઇડકાર ઇન્જેક્ટ કરીએ છીએ તે સફળતાપૂર્વક શરૂ થવી જોઈએ, પાયલોટ પાસેથી બધી શોધ પ્રાપ્ત કરવી જોઈએ અને વિનંતીઓ પર પ્રક્રિયા કરવી જોઈએ.

તે સમજવું અગત્યનું છે કે તમામ કંટ્રોલ પ્લેન ઘટકો સ્ટેટલેસ એપ્લીકેશન છે અને સમસ્યા વિના આડી રીતે માપી શકાય છે. કુબરનેટ્સ સંસાધનોના કસ્ટમ વર્ણનના રૂપમાં તમામ ડેટા વગેરે વગેરેમાં સંગ્રહિત થાય છે.

ઉપરાંત, Istio (હજુ પણ પ્રાયોગિક) ક્લસ્ટરની બહાર દોડવાની ક્ષમતા ધરાવે છે અને કેટલાક કુબરનેટ્સ ક્લસ્ટરો વચ્ચે સેવાની શોધને જોવાની અને તેને હલાવવાની ક્ષમતા ધરાવે છે. તમે આ વિશે વધુ વાંચી શકો છો અહીં.

મલ્ટિ-ક્લસ્ટર ઇન્સ્ટોલેશન માટે, નીચેની મર્યાદાઓથી વાકેફ રહો:

1. Pod CIDR અને સર્વિસ CIDR બધા ક્લસ્ટરોમાં અનન્ય હોવા જોઈએ અને ઓવરલેપ ન થવું જોઈએ.
2. તમામ CIDR પોડ્સ ક્લસ્ટરો વચ્ચેના કોઈપણ CIDR પોડ્સમાંથી ઍક્સેસિબલ હોવા જોઈએ.
3. બધા Kubernetes API સર્વર્સ એકબીજા માટે સુલભ હોવા જોઈએ.

Istio સાથે પ્રારંભ કરવામાં તમને મદદ કરવા માટે આ પ્રારંભિક માહિતી છે. જો કે, હજુ પણ ઘણી ક્ષતિઓ છે. ઉદાહરણ તરીકે, બાહ્ય ટ્રાફિકને (ક્લસ્ટરની બહાર) રૂટીંગ કરવાની વિશેષતાઓ, સાઇડકાર્સને ડિબગ કરવા માટેનો અભિગમ, પ્રોફાઇલિંગ, મિક્સર સેટઅપ અને કસ્ટમ મિક્સર બેકએન્ડ લખવા, ટ્રેસિંગ મિકેનિઝમ સેટ કરવું અને દૂતનો ઉપયોગ કરીને તેની કામગીરી.
આ બધું આપણે નીચેના પ્રકાશનોમાં ધ્યાનમાં લઈશું. તમારા પ્રશ્નો પૂછો, હું તેમને આવરી લેવાનો પ્રયત્ન કરીશ.

સોર્સ: www.habr.com