Cara memulai Istio menggunakan Kubernetes dalam produksi. Bagian 1

Apa itu Istio ? Inilah yang disebut Service mesh, teknologi yang menambahkan lapisan abstraksi melalui jaringan. Kami mencegat semua atau sebagian lalu lintas di cluster 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 layanan yang baru, dan kami dapat membatasi interaksi eksternal dan mengontrol semua perjalanan dari cluster ke jaringan eksternal. Dimungkinkan untuk menetapkan aturan kebijakan untuk mengontrol kampanye di antara berbagai layanan mikro. Akhirnya, kita bisa mendapatkan seluruh peta interaksi melalui jaringan dan membuat kumpulan metrik yang seragam sepenuhnya transparan untuk aplikasi.

Tentang mekanisme kerja dapat ditemukan di dokumentasi resmi . Istio adalah alat yang sangat kuat yang dapat memecahkan banyak masalah dan masalah. Pada artikel ini, saya ingin menjawab pertanyaan dasar yang biasanya muncul pada awal bekerja dengan Istio. Ini akan membantu Anda menghadapinya lebih cepat.

Prinsip kerja

Istio terdiri dari dua zona utama - bidang kontrol dan bidang data. Pesawat kontrol berisi komponen utama yang memastikan operasi yang benar dari yang lain. Dalam versi saat ini (1.0), bidang kontrol memiliki tiga komponen utama: Pilot, Mixer, Citadel. Kami tidak akan mempertimbangkan Citadel, diperlukan untuk menghasilkan sertifikat untuk memastikan TLS saling antara layanan. Mari kita melihat lebih dekat perangkat dan tujuan Pilot dan Mixer.



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

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

Pesawat data diimplementasikan menggunakan wadah proxy sespan. Secara default, server proxy utusan kuat digunakan . Itu bisa diganti dengan implementasi lain, misalnya nginx (nginmesh).

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

Wadah sespan terhubung ke Pilot melalui protokol GRPC, yang memungkinkan mengoptimalkan model mendorong perubahan yang terjadi di cluster. GRPC mulai digunakan di Utusan sejak versi 1.6, di Istio telah digunakan sejak versi 0.8 dan merupakan pilot-agent - pembungkus golang di atas utusan, yang mengonfigurasi parameter peluncuran.

Pilot dan Mixer adalah komponen yang sepenuhnya stateless, semua status disimpan dalam memori. Konfigurasi untuk mereka ditentukan sebagai Sumber Kustom Kubernetes, yang disimpan di etcd.
Agen-Istio menerima alamat Pilot dan membuka aliran GRPC ke sana.

Seperti yang saya katakan, Istio mengimplementasikan semua fungsi yang sepenuhnya transparan untuk aplikasi. Mari kita cari tahu caranya. Algoritma adalah sebagai berikut:

1. Menyebarkan versi baru dari layanan.
2. Bergantung pada pendekatan menyuntikkan wadah sespan, wadah istio-init dan wadah istio-agen (utusan) ditambahkan pada tahap penerapan konfigurasi, atau mereka sudah dapat secara manual dimasukkan ke dalam deskripsi Pod entitas Kubernetes.
3. Wadah istio-init adalah skrip yang menerapkan aturan iptables untuk perapian. Ada dua opsi untuk mengatur pembungkus lalu lintas dalam wadah istio-agent: gunakan aturan redirect iptables, atau TPROXY . Pada saat penulisan, pendekatan standar dengan aturan pengalihan digunakan. Dalam istio-init dimungkinkan untuk mengkonfigurasi lalu lintas mana yang perlu dicegat dan dialihkan ke agen-istio. Misalnya, untuk mencegat semua lalu lintas masuk dan keluar, Anda perlu mengatur parameter -i dan -b ke * . Anda dapat menentukan port tertentu yang akan dicegat. Agar tidak mencegat subnet tertentu, Anda dapat menentukannya menggunakan flag -x .
4. Setelah eksekusi kontainer init, yang utama diluncurkan, termasuk pilot-agent (utusan). Ini terhubung ke Pilot yang sudah dikerahkan melalui GRPC dan menerima informasi tentang semua layanan yang ada dan kebijakan perutean di cluster. Menurut data yang diterima, dia mengkonfigurasi cluster dan secara langsung menetapkan titik akhir aplikasi kita di cluster Kubernetes. Perlu juga dicatat poin penting: utusan secara dinamis mengatur pendengar (IP, pasangan port) yang mulai didengarkan. Oleh karena itu, ketika permintaan memasuki pod, mereka dialihkan menggunakan aturan redirect iptables di sespan, utusan sudah dapat berhasil memproses koneksi ini dan memahami di mana untuk proxy lalu lintas lebih lanjut. Juga pada tahap ini, informasi dikirim ke Mixer, yang akan kita bahas nanti, dan mengirimkan tracing span.

Hasilnya, kami mendapatkan seluruh jaringan server proxy utusan, yang dapat kami konfigurasi dari satu titik (Pilot). Semua permintaan masuk dan keluar melalui utusan. Selain itu, hanya lalu lintas TCP yang dicegat. Ini berarti bahwa layanan IP Kubernetes diselesaikan menggunakan kube-dns melalui UDP tanpa mengubah. Kemudian, setelah menyelesaikan, permintaan keluar dicegat dan diproses oleh utusan, yang sudah memutuskan titik akhir untuk mengirim permintaan ke (atau tidak, dalam hal kebijakan akses atau memicu algoritma pemutus sirkuit).

Dengan Pilot yang disortir, sekarang Anda perlu memahami cara kerja Mixer dan mengapa itu diperlukan. Anda dapat membaca dokumentasi resmi di sini .

Mixer dalam bentuk saat ini terdiri dari dua komponen: istio-telemetri, istio-kebijakan (sebelum versi 0.8 itu adalah salah satu komponen dari istio-mixer). Keduanya adalah mixer, yang masing-masing bertanggung jawab atas tugasnya. Telemetri Istio menerima melalui GRPC dari sespan Laporan wadah informasi tentang siapa yang pergi ke mana dan dengan parameter apa. Kebijakan-Istio menerima permintaan Periksa untuk memeriksa apakah aturan Kebijakan dipenuhi. Pemeriksaan poilicy dilakukan, tentu saja, bukan untuk setiap permintaan, tetapi di-cache pada klien (dalam sespan) untuk waktu tertentu. Laporan cek dikirim oleh permintaan batch. Kita akan melihat nanti bagaimana mengkonfigurasi dan parameter mana yang perlu Anda kirim.

Mixer seharusnya merupakan komponen yang sangat tersedia yang memberikan pekerjaan tanpa gangguan pada pengumpulan dan pemrosesan data telemetri. Sistem berubah menjadi penyangga multi-level. Awalnya, data buffer di sisi sespan wadah, kemudian di sisi mixer dan kemudian dikirim ke backend mixer yang disebut. Akibatnya, jika salah satu komponen sistem gagal, buffer tumbuh dan lumpuh setelah pemulihan sistem. Backend mixer adalah titik akhir untuk mengirim data telemetri: statsd, newrelic, dll. Anda dapat menulis backend Anda, itu cukup sederhana, dan kami akan melihat bagaimana melakukannya.



Sebagai rangkuman, skema kerja 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 Sidecar memantau bagaimana permintaan layanan 2 berlalu dan menyiapkan informasi yang diperlukan.
4. Kemudian mengirimkannya ke istio-telemetri menggunakan permintaan Laporan.
5. Istio-telemetri menentukan apakah akan mengirim Laporan ini ke backend, ke data mana dan data apa yang akan dikirim.
6. Istio-telemetri mengirimkan data Laporan ke backend jika perlu.

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

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 bidang kontrol utama terletak di sistem-namespace namespace di Kubernetes.

Minimal kami hanya perlu menggunakan Pilot. Untuk melakukan ini, kami akan menggunakan konfigurasi ini.

Dan secara manual mengkonfigurasi sespan penyuntik 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 dapat mulai dengan sukses, Anda perlu mendapatkan ServiceAccount, ClusterRole, ClusterRoleBinding, CRD untuk Pilot, deskripsi yang dapat ditemukan di sini .

Akibatnya, layanan tempat kami menyuntikkan sespan dengan utusan harus mulai dengan sukses, dapatkan semua penemuan dari pilot dan proses permintaan.

Penting untuk dipahami bahwa semua komponen bidang kontrol adalah aplikasi stateless dan dapat diskalakan secara horizontal tanpa masalah. Semua data dalam etcd sebagai deskripsi khusus sumber daya Kubernetes.

Istio juga (sejauh ini secara eksperimental) memiliki kemampuan untuk berjalan di luar cluster dan kemampuan untuk menonton dan mencari-cari penemuan layanan antara beberapa cluster Kubernet. Anda dapat membaca lebih lanjut tentang ini di sini .

Untuk instalasi multi-cluster, batasan berikut harus dipertimbangkan:

1. Pod CIDR dan Layanan CIDR harus unik di semua cluster dan tidak boleh tumpang tindih.
2. Semua CIDR Pod harus tersedia dari CIDR Pod apa pun di antara kluster.
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 routing traffic eksternal (ke luar cluster), pendekatan untuk debugging sespan, profiling, pengaturan mixer dan penulisan backend mixer kustom, pengaturan mekanisme pelacakan dan operasinya menggunakan utusan.
Kami akan mempertimbangkan semua ini dalam publikasi berikut. Ajukan pertanyaan Anda, saya akan mencoba untuk membahasnya.