ProHoster > blog > administrasi > Cara menjalankan Istio menggunakan Kubernetes dalam produksi. Bagian 1

Cara menjalankan Istio menggunakan Kubernetes dalam produksi. Bagian 1

Apa Istio? Inilah yang disebut Service mesh, sebuah teknologi yang menambahkan lapisan abstraksi melalui jaringan. Kami mencegat semua atau sebagian lalu lintas di kluster dan melakukan serangkaian operasi tertentu dengannya. Yang mana? Misalnya, kami melakukan perutean pintar, atau kami menerapkan pendekatan pemutus sirkuit, kami dapat mengatur "penyebaran kenari", mengalihkan sebagian lalu lintas ke versi baru layanan, atau kami dapat membatasi interaksi eksternal dan mengontrol semua perjalanan dari klaster ke jaringan eksternal. Dimungkinkan untuk menetapkan aturan kebijakan untuk mengontrol perjalanan antara layanan mikro yang berbeda. Terakhir, kita bisa mendapatkan seluruh peta interaksi jaringan dan membuat kumpulan metrik terpadu benar-benar transparan untuk aplikasi.

Anda dapat membaca tentang mekanisme kerja di dokumentasi resmi. Istio adalah alat yang sangat ampuh yang memungkinkan Anda menyelesaikan banyak tugas dan masalah. Pada artikel ini, saya ingin menjawab pertanyaan utama yang biasanya muncul saat memulai dengan Istio. Ini akan membantu Anda menghadapinya lebih cepat.

Cara menjalankan Istio menggunakan Kubernetes dalam produksi. Bagian 1

Prinsip operasi

Istio terdiri dari dua area utama - bidang kontrol dan bidang data. Bidang kontrol berisi komponen utama yang memastikan operasi yang benar dari yang lain. Pada versi saat ini (1.0) control plane memiliki tiga komponen utama: Pilot, Mixer, Citadel. Kami tidak akan mempertimbangkan Citadel, ini diperlukan untuk menghasilkan sertifikat guna memastikan TLS timbal balik antar layanan. Mari kita lihat lebih dekat perangkat dan tujuan dari Pilot dan Mixer.

Cara menjalankan Istio menggunakan Kubernetes dalam produksi. Bagian 1

Pilot adalah komponen kontrol utama yang mendistribusikan semua informasi tentang apa yang kita miliki di cluster - layanan, titik akhir dan aturan perutean mereka (misalnya, aturan untuk penyebaran Canary atau aturan pemutus sirkuit).

Mixer adalah komponen bidang kontrol opsional yang menyediakan kemampuan untuk mengumpulkan metrik, log, dan informasi apa pun tentang interaksi jaringan. Dia juga memantau kepatuhan terhadap aturan Kebijakan dan kepatuhan terhadap batas tarif.

Pesawat data diimplementasikan menggunakan wadah proxy sespan. Kuat digunakan secara default. wakil utusan. Itu bisa diganti dengan implementasi lain, seperti nginx (nginmesh).

Agar Istio bekerja sepenuhnya transparan terhadap aplikasi, ada sistem injeksi otomatis. Implementasi terbaru cocok untuk versi Kubernetes 1.9+ (webhook penerimaan mutasi). Untuk Kubernetes versi 1.7, 1.8 dimungkinkan untuk menggunakan Penginisialisasi.

Kontainer sespan terhubung ke Pilot menggunakan protokol GRPC, yang memungkinkan Anda mengoptimalkan model push untuk perubahan yang terjadi di klaster. GRPC telah digunakan di Envoy sejak versi 1.6, di Istio telah digunakan sejak versi 0.8 dan merupakan agen percontohan - pembungkus golang di atas utusan yang mengonfigurasi opsi peluncuran.

Pilot dan Mixer adalah komponen tanpa kewarganegaraan, semua status disimpan dalam memori. Konfigurasi untuk mereka diatur dalam bentuk Sumber Daya Kustom Kubernetes, yang disimpan di etcd.
Istio-agent mendapatkan alamat Pilot dan membuka aliran GRPC ke sana.

Seperti yang saya katakan, Istio mengimplementasikan semua fungsi yang sepenuhnya transparan untuk aplikasi. Mari kita lihat caranya. Algoritmanya adalah ini:

  1. Menyebarkan versi baru layanan.
  2. Bergantung pada pendekatan injecting container sidecar, container istio-init dan container istio-agent (envoy) ditambahkan pada tahap penerapan konfigurasi, atau keduanya sudah dapat dimasukkan secara manual ke dalam deskripsi entitas Pod Kubernetes.
  3. Kontainer istio-init adalah skrip yang menerapkan aturan iptables ke pod. Ada dua opsi untuk mengonfigurasi lalu lintas agar dibungkus dalam wadah istio-agent: gunakan aturan pengalihan iptables, atau PROKSI. Pada saat penulisan, pendekatan default adalah dengan aturan redirect. Di istio-init, dimungkinkan untuk mengonfigurasi lalu lintas mana yang harus dicegat dan dikirim ke istio-agent. Misalnya, untuk mencegat semua lalu lintas masuk dan keluar, Anda perlu mengatur parameternya -i ΠΈ -b ke dalam makna *. Anda dapat menentukan port tertentu untuk dicegat. Agar tidak mencegat subnet tertentu, Anda dapat menentukannya menggunakan flag -x.
  4. Setelah init container dijalankan, yang utama diluncurkan, termasuk pilot-agent (utusan). Itu terhubung ke Pilot yang sudah dikerahkan melalui GRPC dan menerima informasi tentang semua layanan yang ada dan kebijakan perutean di kluster. Menurut data yang diterima, dia mengonfigurasi cluster dan menetapkannya langsung ke titik akhir aplikasi kami di cluster Kubernetes. Penting juga untuk mencatat poin penting: utusan secara dinamis mengonfigurasi pendengar (IP, pasangan port) yang mulai didengarkan. Oleh karena itu, ketika permintaan masuk ke pod, dialihkan menggunakan aturan redirect iptables di sidecar, utusan sudah berhasil memproses koneksi ini dan memahami ke mana harus mem-proxy lalu lintas lebih lanjut. Juga pada tahap ini, informasi dikirim ke Mixer, yang akan kita lihat nanti, dan rentang penelusuran dikirim.

Hasilnya, kami mendapatkan seluruh jaringan server proxy utusan yang dapat kami konfigurasikan dari satu titik (Pilot). Semua permintaan masuk dan keluar melalui utusan. Selain itu, hanya lalu lintas TCP yang dicegat. Artinya, IP layanan Kubernetes diselesaikan menggunakan kube-dns melalui UDP tanpa perubahan. Kemudian, setelah penyelesaian, permintaan keluar dicegat dan diproses oleh utusan, yang telah memutuskan ke titik akhir mana permintaan harus dikirim (atau tidak dikirim, dalam hal kebijakan akses atau pemutus sirkuit algoritme).

Kami menemukan Pilot, sekarang kami perlu memahami cara kerja Mixer dan mengapa itu diperlukan. Anda dapat membaca dokumentasi resmi untuk itu di sini.

Mixer dalam bentuknya yang sekarang terdiri dari dua komponen: istio-telemetry, istio-policy (sebelum versi 0.8 merupakan salah satu komponen istio-mixer). Keduanya merupakan pencampur yang masing-masing bertanggung jawab atas tugasnya masing-masing. Telemetri Istio menerima informasi tentang siapa pergi ke mana dan dengan parameter apa dari wadah Laporan sespan melalui GRPC. Istio-policy menerima permintaan Periksa untuk memverifikasi bahwa aturan Kebijakan dipenuhi. Pemeriksaan kebijakan, tentu saja, tidak dilakukan untuk setiap permintaan, tetapi di-cache pada klien (di sespan) untuk waktu tertentu. Pemeriksaan laporan dikirim sebagai permintaan batch. Mari kita lihat cara mengonfigurasi dan parameter apa yang harus dikirim nanti.

Mixer seharusnya menjadi komponen yang sangat tersedia yang memastikan pekerjaan tanpa gangguan pada perakitan dan pemrosesan data telemetri. Sistem ini diperoleh sebagai buffer multi-level. Awalnya, data di-buffer di sisi sidecar container, kemudian di sisi mixer, dan kemudian dikirim ke apa yang disebut backend mixer. Akibatnya, jika salah satu komponen sistem gagal, buffer tumbuh dan dibilas setelah sistem dipulihkan. Backend mixer adalah titik akhir untuk mengirim data telemetri: statsd, newrelic, dll. Anda dapat menulis backend Anda sendiri, ini cukup sederhana, dan kami akan melihat cara melakukannya.

Cara menjalankan Istio menggunakan Kubernetes dalam produksi. Bagian 1

Singkatnya, skema untuk bekerja dengan istio-telemetri adalah sebagai berikut.

  1. Layanan 1 mengirimkan permintaan ke layanan 2.
  2. Saat meninggalkan layanan 1, permintaan dibungkus dengan sespannya sendiri.
  3. Utusan sespan memantau bagaimana permintaan masuk ke layanan 2 dan menyiapkan informasi yang diperlukan.
  4. Kemudian mengirimkannya ke istio-telemetri menggunakan permintaan Laporan.
  5. Istio-telemetri menentukan apakah Laporan ini harus dikirim ke backend, ke mana dan data apa yang harus dikirim.
  6. Istio-telemetri mengirimkan data Laporan ke backend jika diperlukan.

Sekarang mari kita lihat bagaimana menerapkan Istio dalam sistem, yang hanya terdiri dari komponen utama (Pilot dan utusan sespan).

Pertama, mari kita lihat konfigurasi utama (mesh) yang dibaca 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 kontrol utama (bidang kontrol) akan ditempatkan di namespace istio-system di Kubernetes.

Minimal, kita hanya perlu men-deploy Pilot. Untuk ini kita akan menggunakan konfigurasi seperti itu.

Dan secara manual mengkonfigurasi sespan injeksi wadah.

Wadah init:

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 sespan:

       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 semuanya berhasil dimulai, Anda perlu membuat ServiceAccount, ClusterRole, ClusterRoleBinding, CRD untuk Pilot, yang deskripsinya dapat ditemukan di sini.

Akibatnya, layanan tempat kami menyuntikkan sespan dengan utusan harus dimulai dengan sukses, menerima semua penemuan dari pilot, dan memproses permintaan.

Penting untuk dipahami bahwa semua komponen bidang kontrol adalah aplikasi tanpa kewarganegaraan dan dapat diskalakan secara horizontal tanpa masalah. Semua data disimpan di etcd dalam bentuk deskripsi kustom sumber daya Kubernetes.

Selain itu, Istio (masih dalam tahap percobaan) memiliki kemampuan untuk berjalan di luar cluster dan kemampuan untuk mengamati dan meraba-raba penemuan layanan di antara beberapa cluster Kubernetes. Anda dapat membaca lebih lanjut tentang ini di sini.

Untuk penginstalan multi-cluster, perhatikan batasan berikut:

  1. Pod CIDR dan Service CIDR harus unik di semua cluster dan tidak boleh tumpang tindih.
  2. Semua Pod CIDR harus dapat diakses dari semua Pod CIDR antar cluster.
  3. Semua server API Kubernetes harus dapat diakses satu sama lain.

Ini adalah informasi awal untuk membantu Anda memulai dengan Istio. Namun, masih banyak jebakan. Misalnya, fitur merutekan lalu lintas eksternal (di luar cluster), pendekatan untuk men-debug sidecars, membuat profil, menyiapkan mixer, dan menulis backend mixer khusus, menyiapkan mekanisme penelusuran dan pengoperasiannya menggunakan utusan.
Semua ini akan kami pertimbangkan dalam publikasi berikut. Ajukan pertanyaan Anda, saya akan mencoba untuk menutupinya.

Sumber: www.habr.com

Tambah komentar