🥇Cara menjalankan Istio menggunakan Kubernetes dalam pengeluaran. Bahagian 1

Apakah Istio? Ini adalah apa yang dipanggil Service mesh, teknologi yang menambah lapisan abstraksi ke atas rangkaian. Kami memintas semua atau sebahagian daripada trafik dalam kelompok dan melakukan set operasi tertentu dengannya. Yang mana satu? Sebagai contoh, kami melakukan penghalaan pintar, atau kami melaksanakan pendekatan pemutus litar, kami boleh mengatur "pengerahan kenari", menukar sebahagian trafik kepada versi baharu perkhidmatan, atau kami boleh mengehadkan interaksi luaran dan mengawal semua perjalanan daripada kluster ke rangkaian luaran. Anda boleh menetapkan peraturan dasar untuk mengawal perjalanan antara perkhidmatan mikro yang berbeza. Akhir sekali, kami boleh mendapatkan keseluruhan peta interaksi rangkaian dan menjadikan koleksi metrik bersatu sepenuhnya telus kepada aplikasi.

Anda boleh membaca tentang mekanisme kerja dalam dokumentasi rasmi. Istio ialah alat yang sangat berkuasa yang membolehkan anda menyelesaikan banyak tugas dan masalah. Dalam artikel ini, saya ingin menjawab soalan utama yang biasanya timbul apabila bermula dengan Istio. Ini akan membantu anda menanganinya dengan lebih cepat.

Prinsip operasi

Istio terdiri daripada dua kawasan utama - satah kawalan dan satah data. Satah kawalan mengandungi komponen utama yang memastikan operasi yang betul bagi selebihnya. Dalam versi semasa (1.0) pesawat kawalan mempunyai tiga komponen utama: Pilot, Mixer, Citadel. Kami tidak akan mempertimbangkan Citadel, ia diperlukan untuk menjana sijil untuk memastikan TLS bersama antara perkhidmatan. Mari kita lihat lebih dekat pada peranti dan tujuan Pilot dan Mixer.

Pilot ialah komponen kawalan utama yang mengedarkan semua maklumat tentang apa yang kita ada dalam kluster - perkhidmatan, titik akhir dan peraturan penghalaan mereka (contohnya, peraturan untuk penggunaan Canary atau peraturan pemutus litar).

Pengadun ialah komponen satah kawalan pilihan yang menyediakan keupayaan untuk mengumpul metrik, log dan sebarang maklumat tentang interaksi rangkaian. Beliau juga memantau pematuhan peraturan Polisi dan pematuhan had kadar.

Pesawat data dilaksanakan menggunakan bekas proksi kereta sampingan. Kuasa digunakan secara lalai. proksi utusan. Ia boleh digantikan dengan pelaksanaan lain, seperti nginx (nginmesh).

Agar Istio berfungsi sepenuhnya telus untuk aplikasi, terdapat sistem suntikan automatik. Pelaksanaan terkini sesuai untuk versi Kubernetes 1.9+ (webhook kemasukan mutasi). Untuk Kubernetes versi 1.7, 1.8 adalah mungkin untuk menggunakan Initializer.

Bekas kereta sisi disambungkan ke Pilot menggunakan protokol GRPC, yang membolehkan anda mengoptimumkan model tolak untuk perubahan yang berlaku dalam kelompok. GRPC telah digunakan dalam Envoy sejak versi 1.6, dalam Istio ia telah digunakan sejak versi 0.8 dan merupakan ejen perintis - pembalut golang atas utusan yang mengkonfigurasi pilihan pelancaran.

Pilot dan Mixer adalah komponen tanpa negara sepenuhnya, semua keadaan disimpan dalam ingatan. Konfigurasi untuk mereka ditetapkan dalam bentuk Kubernetes Custom Resources, yang disimpan dalam etcd.
Istio-agent mendapat alamat Juruterbang dan membuka aliran GRPC kepadanya.

Seperti yang saya katakan, Istio melaksanakan semua fungsi sepenuhnya telus kepada aplikasi. Mari kita lihat bagaimana. Algoritmanya adalah ini:

Menggunakan versi baharu perkhidmatan.
Bergantung pada pendekatan suntikan bekas kereta sisi, bekas istio-init dan bekas ejen istio (utusan) ditambah pada peringkat penggunaan konfigurasi, atau mereka sudah boleh dimasukkan secara manual ke dalam perihalan entiti Kubernetes Pod.
Bekas istio-init ialah skrip yang menggunakan peraturan iptables pada pod. Terdapat dua pilihan untuk mengkonfigurasi trafik untuk dibungkus dalam bekas ejen istio: gunakan peraturan ubah hala iptables, atau TPROXY. Pada masa penulisan, pendekatan lalai adalah dengan peraturan ubah hala. Dalam istio-init, adalah mungkin untuk mengkonfigurasi trafik mana yang harus dipintas dan dihantar ke istio-agent. Contohnya, untuk memintas semua trafik masuk dan semua trafik keluar, anda perlu menetapkan parameter -i и -b menjadi makna *. Anda boleh menentukan port tertentu untuk memintas. Untuk tidak memintas subnet tertentu, anda boleh menentukannya menggunakan bendera -x.
Selepas kontena init dilaksanakan, kontena utama dilancarkan, termasuk ejen perintis (utusan). Ia menyambung kepada Juruterbang yang telah digunakan melalui GRPC dan menerima maklumat tentang semua perkhidmatan sedia ada dan dasar penghalaan dalam kelompok. Menurut data yang diterima, beliau mengkonfigurasi kluster dan menetapkannya terus ke titik akhir aplikasi kami dalam kluster Kubernetes. Ia juga perlu diperhatikan satu perkara penting: utusan secara dinamik mengkonfigurasi pendengar (IP, pasangan port) yang mula didengarinya. Oleh itu, apabila permintaan memasuki pod, diubah hala menggunakan peraturan iptables ubah hala dalam kereta sampingan, utusan sudah boleh berjaya memproses sambungan ini dan memahami tempat untuk memproksi lagi trafik. Juga pada peringkat ini, maklumat dihantar kepada Pengadun, yang akan kita lihat kemudian, dan rentang pengesanan dihantar.

Hasilnya, kami mendapat rangkaian keseluruhan pelayan proksi utusan yang boleh kami konfigurasikan dari satu titik (Pilot). Semua permintaan masuk dan keluar melalui utusan. Lebih-lebih lagi, hanya trafik TCP dipintas. Ini bermakna IP perkhidmatan Kubernetes diselesaikan menggunakan kube-dns melalui UDP tanpa berubah. Kemudian, selepas penyelesaian, permintaan keluar dipintas dan diproses oleh utusan, yang sudah memutuskan titik akhir permintaan itu harus dihantar ke (atau tidak dihantar, dalam kes dasar akses atau pemutus litar algoritma).

Kami mengetahui Pilot, kini kami perlu memahami cara Mixer berfungsi dan mengapa ia diperlukan. Anda boleh membaca dokumentasi rasmi untuknya di sini.

Pengadun dalam bentuk semasanya terdiri daripada dua komponen: istio-telemetri, istio-dasar (sebelum versi 0.8 ia adalah satu komponen istio-pencampur). Kedua-duanya adalah pengadun, masing-masing bertanggungjawab untuk tugasnya sendiri. Telemetri Istio menerima maklumat tentang siapa yang pergi ke mana dan dengan parameter apa daripada bekas Laporkan kereta sampingan melalui GRPC. Istio-policy menerima permintaan Semak untuk mengesahkan bahawa peraturan Dasar dipenuhi. Pemeriksaan polisi, sudah tentu, tidak dijalankan untuk setiap permintaan, tetapi dicache pada pelanggan (dalam kereta sampingan) untuk masa tertentu. Semakan laporan dihantar sebagai permintaan kelompok. Mari lihat cara mengkonfigurasi dan parameter apa yang perlu dihantar sedikit kemudian.

Pengadun sepatutnya menjadi komponen yang sangat tersedia yang memastikan kerja tanpa gangguan pada pemasangan dan pemprosesan data telemetri. Sistem ini diperolehi sebagai hasil sebagai penimbal pelbagai peringkat. Pada mulanya, data ditimbal pada bahagian sisi bekas bekas, kemudian pada bahagian pengadun, dan kemudian dihantar ke bahagian belakang pengadun yang dipanggil. Akibatnya, jika mana-mana komponen sistem gagal, penimbal membesar dan disiram selepas sistem dipulihkan. Bahagian belakang pengadun ialah titik akhir untuk menghantar data telemetri: statsd, newrelic, dsb. Anda boleh menulis bahagian belakang anda sendiri, ia agak mudah, dan kami akan melihat cara melakukannya.

Untuk meringkaskan, skema untuk bekerja dengan istio-telemetri adalah seperti berikut.

Perkhidmatan 1 menghantar permintaan kepada perkhidmatan 2.
Apabila meninggalkan perkhidmatan 1, permintaan itu dibungkus dengan kereta sampingannya sendiri.
Utusan Sidecar memantau cara permintaan pergi ke perkhidmatan 2 dan menyediakan maklumat yang diperlukan.
Kemudian hantar ke istio-telemetri menggunakan permintaan Laporan.
Istio-telemetri menentukan sama ada Laporan ini harus dihantar ke bahagian belakang, ke mana dan data yang perlu dihantar.
Istio-telemetri menghantar data Laporan ke bahagian belakang jika perlu.

Sekarang mari kita lihat cara menggunakan Istio dalam sistem, yang hanya terdiri daripada komponen utama (Pilot dan utusan sidecar).

Pertama, mari kita lihat konfigurasi utama (mesh) yang dibaca oleh Pilot:

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

Semua komponen kawalan utama (satah kawalan) akan ditempatkan dalam sistem istio ruang nama dalam Kubernetes.

Sekurang-kurangnya, kita hanya perlu menggunakan Pilot. Untuk ini kami akan gunakan konfigurasi sedemikian.

Dan kami akan mengkonfigurasi kereta sampingan suntikan bekas itu secara manual.

Init bekas:

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

Dan kereta sampingan:

       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

Agar segala-galanya bermula dengan jayanya, anda perlu mencipta Akaun Perkhidmatan, ClusterRole, ClusterRoleBinding, CRD untuk Pilot, yang penerangannya boleh didapati di sini.

Akibatnya, perkhidmatan di mana kami menyuntik kereta sampingan dengan utusan harus dimulakan dengan jayanya, menerima semua penemuan daripada juruterbang dan memproses permintaan.

Adalah penting untuk memahami bahawa semua komponen satah kawalan adalah aplikasi tanpa kewarganegaraan dan boleh diskalakan secara mendatar tanpa masalah. Semua data disimpan dalam etcd dalam bentuk perihalan tersuai sumber Kubernetes.

Selain itu, Istio (masih eksperimen) mempunyai keupayaan untuk berjalan di luar kluster dan keupayaan untuk menonton dan meraba-raba penemuan perkhidmatan antara beberapa kluster Kubernetes. Anda boleh membaca lebih lanjut mengenai ini di sini.

Untuk pemasangan berbilang kelompok, ketahui batasan berikut:

CIDR Pod dan CIDR Perkhidmatan mestilah unik merentas semua kluster dan tidak boleh bertindih.
Semua Pod CIDR mesti boleh diakses daripada mana-mana Pod CIDR antara kluster.
Semua pelayan API Kubernetes mesti boleh diakses antara satu sama lain.

Ini adalah maklumat awal untuk membantu anda bermula dengan Istio. Walau bagaimanapun, masih terdapat banyak perangkap. Contohnya, ciri penghalaan trafik luaran (di luar kluster), pendekatan untuk menyahpepijat kereta sampingan, memprofil, menyediakan pengadun dan menulis bahagian belakang pengadun tersuai, menyediakan mekanisme pengesanan dan operasinya menggunakan utusan.
Semua ini akan kami pertimbangkan dalam penerbitan berikut. Tanya soalan anda, saya akan cuba menjawabnya.

Sumber: www.habr.com

Cara menjalankan Istio menggunakan Kubernetes dalam pengeluaran. Bahagian 1

Prinsip operasi

Tambah komen Batal reply