როგორ გავუშვათ ისტიო Kubernetes-ის გამოყენებით წარმოებაში. Ნაწილი 1

რა არის ისტიო? ეს არის ეგრეთ წოდებული Service mesh, ტექნოლოგია, რომელიც ამატებს აბსტრაქციის ფენას ქსელში. ჩვენ ვწყვეტთ კლასტერში ტრაფიკის მთელ ან ნაწილს და მასთან ერთად ვასრულებთ ოპერაციების გარკვეულ კომპლექტს. Რომელი? მაგალითად, ჩვენ ვაკეთებთ ჭკვიან მარშრუტიზაციას, ან ვახორციელებთ ამომრთველების მიდგომას, შეგვიძლია მოვაწყოთ „კანარის განლაგება“, ნაწილობრივ გადავრთოთ ტრაფიკი სერვისის ახალ ვერსიაზე, ან შეგვიძლია შევზღუდოთ გარე ურთიერთქმედებები და ვაკონტროლოთ ყველა მგზავრობა კლასტერიდან გარე ქსელი. შესაძლებელია დაწესდეს პოლიტიკის წესები სხვადასხვა მიკროსერვისებს შორის მოგზაურობის გასაკონტროლებლად. საბოლოოდ, ჩვენ შეგვიძლია მივიღოთ მთელი ქსელის ურთიერთქმედების რუკა და გავხადოთ მეტრიკის ერთიანი კოლექცია აპლიკაციებისთვის სრულიად გამჭვირვალე.

მუშაობის მექანიზმის შესახებ შეგიძლიათ წაიკითხოთ ოფიციალური დოკუმენტაცია. Istio არის მართლაც ძლიერი ინსტრუმენტი, რომელიც საშუალებას გაძლევთ გადაჭრათ მრავალი ამოცანა და პრობლემა. ამ სტატიაში მსურს ვუპასუხო მთავარ კითხვებს, რომლებიც ჩვეულებრივ ჩნდება Istio-ს დაწყებისას. ეს დაგეხმარებათ უფრო სწრაფად გაუმკლავდეთ მას.

პრინციპი ოპერაციის

ისტიო შედგება ორი ძირითადი სფეროსგან - საკონტროლო სიბრტყე და მონაცემთა სიბრტყე. საკონტროლო თვითმფრინავი შეიცავს ძირითად კომპონენტებს, რომლებიც უზრუნველყოფენ დანარჩენის სწორ მუშაობას. მიმდინარე ვერსიაში (1.0) საკონტროლო თვითმფრინავს აქვს სამი ძირითადი კომპონენტი: პილოტი, მიქსერი, ციტადელი. ჩვენ არ განვიხილავთ ციტადელს, საჭიროა სერთიფიკატების გენერირება სერვისებს შორის ურთიერთ TLS-ის უზრუნველსაყოფად. მოდით უფრო ახლოს მივხედოთ Pilot and Mixer-ის მოწყობილობასა და დანიშნულებას.

პილოტი არის მთავარი კონტროლის კომპონენტი, რომელიც ავრცელებს მთელ ინფორმაციას იმის შესახებ, რაც გვაქვს კლასტერში - სერვისები, მათი ბოლო წერტილები და მარშრუტის წესები (მაგალითად, კანარის განლაგების წესები ან ამომრთველის წესები).

მიქსერი არის არჩევითი საკონტროლო სიბრტყის კომპონენტი, რომელიც უზრუნველყოფს მეტრიკის, ჟურნალის და ქსელის ურთიერთქმედების შესახებ ნებისმიერი ინფორმაციის შეგროვების შესაძლებლობას. ის ასევე აკონტროლებს პოლიტიკის წესებთან შესაბამისობას და განაკვეთების ლიმიტებთან შესაბამისობას.

მონაცემთა სიბრტყე განხორციელებულია sidecar proxy კონტეინერების გამოყენებით. ძლიერი გამოიყენება ნაგულისხმევად. დესპანის მარიონეტული. ის შეიძლება შეიცვალოს სხვა განხორციელებით, როგორიცაა nginx (nginmesh).

იმისათვის, რომ Istio იმუშაოს აპლიკაციებისთვის სრულიად გამჭვირვალე, არსებობს ავტომატური ინექციის სისტემა. უახლესი იმპლემენტაცია შესაფერისია Kubernetes 1.9+ ვერსიებისთვის (მუტაციური დაშვების webhook). Kubernetes 1.7, 1.8 ვერსიებისთვის შესაძლებელია ინიციალატორის გამოყენება.

Sidecar-ის კონტეინერები დაკავშირებულია Pilot-თან GRPC პროტოკოლის გამოყენებით, რომელიც საშუალებას გაძლევთ ოპტიმიზაცია მოახდინოთ push მოდელის კლასტერში მომხდარი ცვლილებებისთვის. GRPC გამოიყენებოდა Envoy-ში 1.6 ვერსიიდან, Istio-ში იგი გამოიყენება 0.8 ვერსიიდან და არის პილოტი-აგენტი - გოლანგის შეფუთვა ელფერზე, რომელიც აკონფიგურირებს გაშვების ვარიანტებს.

პილოტი და მიქსერი არის სრულიად უსახელო კომპონენტები, ყველა მდგომარეობა ინახება მეხსიერებაში. მათთვის კონფიგურაცია დაყენებულია Kubernetes Custom Resources-ის სახით, რომელიც ინახება etcd-ში.
ისტიო-აგენტი იღებს პილოტის მისამართს და ხსნის მას GRPC ნაკადს.

როგორც ვთქვი, Istio ახორციელებს ყველა ფუნქციონირებას აპლიკაციებისთვის სრულიად გამჭვირვალე. ვნახოთ როგორ. ალგორითმი ასეთია:

1. სერვისის ახალი ვერსიის დანერგვა.
2. გვერდითი კარის კონტეინერის ინექციის მიდგომიდან გამომდინარე, istio-init კონტეინერი და istio-აგენტის კონტეინერი (დესპანი) ემატება კონფიგურაციის გამოყენების ეტაპზე, ან უკვე შესაძლებელია მათი ხელით ჩასმა Kubernetes Pod ერთეულის აღწერაში.
3. istio-init კონტეინერი არის სკრიპტი, რომელიც იყენებს iptables წესებს პოდზე. არსებობს ორი ვარიანტი ტრაფიკის კონფიგურაციისთვის, რომელიც შეფუთულია istio-აგენტის კონტეინერში: გამოიყენეთ iptables გადამისამართების წესები, ან TPROXY. წერის დროს ნაგულისხმევი მიდგომა არის გადამისამართების წესები. istio-init-ში შესაძლებელია დააკონფიგურიროთ, რომელი ტრაფიკი უნდა ჩაეჭრას და გაიგზავნოს istio-აგენტს. მაგალითად, ყველა შემომავალი და გამავალი ტრაფიკის გადასაჭრელად, თქვენ უნდა დააყენოთ პარამეტრები -i и -b მნიშვნელობაში *. თქვენ შეგიძლიათ მიუთითოთ კონკრეტული პორტები ჩარევისთვის. იმისათვის, რომ არ მოხდეს კონკრეტული ქვექსელის ჩარევა, შეგიძლიათ მიუთითოთ იგი დროშის გამოყენებით -x.
4. საწყის კონტეინერების შესრულების შემდეგ, იშვება ძირითადი, მათ შორის პილოტ-აგენტი (დესპანი). ის უერთდება უკვე განლაგებულ პილოტს GRPC-ის საშუალებით და იღებს ინფორმაციას კლასტერში არსებული ყველა სერვისისა და მარშრუტიზაციის პოლიტიკის შესახებ. მიღებული მონაცემების მიხედვით, ის აკონფიგურირებს კლასტერებს და ანიჭებს მათ პირდაპირ კუბერნეტის კლასტერში ჩვენი აპლიკაციების ბოლო წერტილებს. ასევე აუცილებელია აღინიშნოს მნიშვნელოვანი პუნქტი: envoy დინამიურად აკონფიგურირებს მსმენელებს (IP, პორტების წყვილები), რომელთა მოსმენას იწყებს. ამიტომ, როდესაც მოთხოვნები შედის პოდში, გადამისამართდება iptables-ის გადამისამართების წესების გამოყენებით sidecar-ში, დესპანს უკვე შეუძლია წარმატებით დაამუშაოს ეს კავშირები და გაიგოს, თუ სად შეიძლება შემდგომი მარიონეტული ტრაფიკი. ასევე ამ ეტაპზე, ინფორმაცია იგზავნება Mixer-ში, რომელსაც მოგვიანებით განვიხილავთ და იგზავნება ტრასირების სპანები.

შედეგად, ჩვენ ვიღებთ envoy proxy სერვერების მთელ ქსელს, რომელთა კონფიგურაცია შეგვიძლია ერთი წერტილიდან (პილოტი). ყველა შემომავალი და გამავალი მოთხოვნა გადის დესპანის მეშვეობით. უფრო მეტიც, მხოლოდ TCP ტრაფიკი ჩერდება. ეს ნიშნავს, რომ Kubernetes სერვისის IP გადაწყვეტილია Kube-dns-ის გამოყენებით UDP-ზე შეცვლის გარეშე. ამის შემდეგ, გადაწყვეტის შემდეგ, გამავალი მოთხოვნა ჩაითვლება და მუშავდება დესპანის მიერ, რომელიც უკვე წყვეტს, რომელ ბოლო წერტილში უნდა გაიგზავნოს მოთხოვნა (ან არ გაიგზავნოს, წვდომის პოლიტიკის ან ალგორითმის ამომრთველის გააქტიურების შემთხვევაში).

ჩვენ გავარკვიეთ Pilot, ახლა ჩვენ უნდა გავიგოთ, როგორ მუშაობს Mixer და რატომ არის საჭირო. თქვენ შეგიძლიათ წაიკითხოთ ოფიციალური დოკუმენტაცია აქ.

მიქსერი მისი ამჟამინდელი ფორმით შედგება ორი კომპონენტისგან: ისტიო-ტელემეტრია, ისტოპოლიტიკა (0.8 ვერსიამდე ეს იყო ერთი ისტო-მიქსერის კომპონენტი). ორივე მათგანი არის მიქსერი, რომელთაგან თითოეული პასუხისმგებელია საკუთარ ამოცანაზე. Istio telemetry იღებს ინფორმაციას იმის შესახებ, თუ ვინ სად მიდის და რა პარამეტრებით გვერდითი კარის ანგარიშის კონტეინერებიდან GRPC-ის საშუალებით. Istio-პოლისი იღებს შემოწმების მოთხოვნებს, რათა შეამოწმოს, რომ პოლიტიკის წესები დაკმაყოფილებულია. პოლიტიკის შემოწმებები, რა თქმა უნდა, არ ტარდება ყველა მოთხოვნისთვის, მაგრამ ინახება კლიენტზე (გვერდითა კარში) გარკვეული დროის განმავლობაში. მოხსენების შემოწმებები იგზავნება პარტიული მოთხოვნის სახით. ვნახოთ, როგორ უნდა მოხდეს კონფიგურაცია და რა პარამეტრები უნდა გაიგზავნოს ცოტა მოგვიანებით.

მიქსერი უნდა იყოს უაღრესად ხელმისაწვდომი კომპონენტი, რომელიც უზრუნველყოფს ტელემეტრიული მონაცემების შეკრებასა და დამუშავებაზე შეუფერხებელ მუშაობას. სისტემა მიიღება შედეგად, როგორც მრავალ დონის ბუფერი. თავდაპირველად, მონაცემები ბუფერდება კონტეინერების გვერდითა მხარეს, შემდეგ მიქსერის მხარეს და შემდეგ იგზავნება ე.წ. შედეგად, თუ სისტემის რომელიმე კომპონენტი ვერ ხერხდება, ბუფერი იზრდება და ჩამოირეცხება სისტემის აღდგენის შემდეგ. Mixer backends არის ბოლო წერტილები ტელემეტრიული მონაცემების გაგზავნისთვის: statsd, newrelic და ა.შ. თქვენ შეგიძლიათ დაწეროთ თქვენი საკუთარი ბექენდი, ეს საკმაოდ მარტივია და ჩვენ ვნახავთ, როგორ გავაკეთოთ ეს.

რომ შევაჯამოთ, ისტიო-ტელემეტრიასთან მუშაობის სქემა ასეთია.

1. სერვისი 1 აგზავნის მოთხოვნას სერვის 2-ზე.
2. სერვისი 1-ის დატოვებისას, მოთხოვნა შეფუთულია საკუთარ გვერდით კარში.
3. Sidecar დესპანი აკონტროლებს, თუ როგორ მიდის მოთხოვნა სერვის 2-ში და ამზადებს საჭირო ინფორმაციას.
4. შემდეგ აგზავნის მას istio-telemetry-ში მოხსენების მოთხოვნის გამოყენებით.
5. ისტიო-ტელემეტრია განსაზღვრავს, უნდა გაიგზავნოს თუ არა ეს მოხსენება ბექენდებში, რომელ და რა მონაცემები უნდა გაიგზავნოს.
6. Istio-telemetry აგზავნის მოხსენების მონაცემებს ბექენდში, საჭიროების შემთხვევაში.

ახლა ვნახოთ, როგორ განვათავსოთ ისტიო სისტემაში, რომელიც შედგება მხოლოდ ძირითადი კომპონენტებისგან (პილოტი და გვერდითი დესპანი).

პირველ რიგში, მოდით შევხედოთ მთავარ კონფიგურაციას (ბადე), რომელსაც პილოტი კითხულობს:

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-ის სახელთა სივრცის istio-სისტემაში.

მინიმუმ, ჩვენ მხოლოდ პილოტის განლაგება გვჭირდება. ამისთვის გამოვიყენებთ ასეთი კონფიგურაცია.

და ჩვენ ხელით დავაკონფიგურირებთ კონტეინერის ინექციური გვერდითი კარის კონფიგურაციას.

საწყისი კონტეინერი:

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 Pilot-ისთვის, რომლის აღწერილობებიც შეგიძლიათ ნახოთ. აქ.

შედეგად, სერვისი, რომელშიც ჩვენ დესპანთან ერთად ჩავრთავთ გვერდით კარს, წარმატებით უნდა დაიწყოს, მიიღოს ყველა აღმოჩენა პილოტისგან და დაამუშავოს მოთხოვნები.

მნიშვნელოვანია გვესმოდეს, რომ საკონტროლო სიბრტყის ყველა კომპონენტი არის მოქალაქეობის არმქონე აპლიკაციები და შეიძლება ჰორიზონტალურად მასშტაბური იყოს პრობლემების გარეშე. ყველა მონაცემი ინახება etcd-ში Kubernetes-ის რესურსების მორგებული აღწერილობის სახით.

ასევე, Istio-ს (ჯერ კიდევ ექსპერიმენტულ) აქვს კასეტურის გარეთ გაშვების შესაძლებლობა და კუბერნეტის რამდენიმე კლასტერს შორის სერვისის აღმოჩენის ყურების და ჭვრეტის შესაძლებლობა. ამის შესახებ მეტი შეგიძლიათ წაიკითხოთ აქ.

მრავალკლასტერული ინსტალაციისთვის, გაითვალისწინეთ შემდეგი შეზღუდვები:

1. Pod CIDR და Service CIDR უნდა იყოს უნიკალური ყველა კლასტერში და არ უნდა გადაფარონ.
2. ყველა CIDR Pods უნდა იყოს ხელმისაწვდომი ნებისმიერი CIDR Pods-დან კლასტერებს შორის.
3. ყველა Kubernetes API სერვერი უნდა იყოს ერთმანეთთან წვდომა.

ეს არის საწყისი ინფორმაცია, რომელიც დაგეხმარებათ დაიწყოთ ისტიო. თუმცა, ჯერ კიდევ ბევრი ხარვეზია. მაგალითად, გარე ტრაფიკის მარშრუტის მახასიათებლები (კლასტერის გარეთ), გვერდითი კარების გამართვის მიდგომები, პროფილირება, მიქსერის დაყენება და მორგებული მიქსერის დასაწერი ნაწილის დაწერა, ტრასირების მექანიზმის დაყენება და მისი ფუნქციონირება envoy-ის გამოყენებით.
ამ ყველაფერს განვიხილავთ შემდეგ პუბლიკაციებში. დასვით თქვენი შეკითხვები, ვეცდები მათ გაშუქებას.

წყარო: www.habr.com