Τι είναι ? Αυτό είναι το λεγόμενο Service mesh, μια τεχνολογία που προσθέτει ένα επίπεδο αφαίρεσης στο δίκτυο. Αναχαιτίζουμε το σύνολο ή μέρος της κίνησης στο σύμπλεγμα και εκτελούμε ένα συγκεκριμένο σύνολο λειτουργιών με αυτό. Ποιό απ'όλα? Για παράδειγμα, κάνουμε έξυπνη δρομολόγηση ή εφαρμόζουμε την προσέγγιση του διακόπτη κυκλώματος, μπορούμε να οργανώσουμε την "ανάπτυξη καναρινιών", μεταβάλλοντας εν μέρει την κυκλοφορία σε μια νέα έκδοση της υπηρεσίας ή μπορούμε να περιορίσουμε τις εξωτερικές αλληλεπιδράσεις και να ελέγξουμε όλες τις διαδρομές από το σύμπλεγμα στο εξωτερικό δίκτυο. Είναι δυνατό να τεθούν κανόνες πολιτικής για τον έλεγχο των ταξιδιών μεταξύ διαφορετικών μικροϋπηρεσιών. Τέλος, μπορούμε να λάβουμε ολόκληρο τον χάρτη αλληλεπίδρασης δικτύου και να κάνουμε την ενοποιημένη συλλογή μετρήσεων εντελώς διαφανή στις εφαρμογές.
Μπορείτε να διαβάσετε για τον μηχανισμό εργασίας στο . Το Istio είναι ένα πραγματικά ισχυρό εργαλείο που σας επιτρέπει να λύσετε πολλές εργασίες και προβλήματα. Σε αυτό το άρθρο, θα ήθελα να απαντήσω στις κύριες ερωτήσεις που συνήθως προκύπτουν όταν ξεκινάτε με το Istio. Αυτό θα σας βοηθήσει να το αντιμετωπίσετε πιο γρήγορα.
Αρχή της λειτουργίας
Το Ίστιο αποτελείται από δύο κύριες περιοχές - το επίπεδο ελέγχου και το επίπεδο δεδομένων. Το επίπεδο ελέγχου περιέχει τα κύρια εξαρτήματα που διασφαλίζουν τη σωστή λειτουργία των υπολοίπων. Στην τρέχουσα έκδοση (1.0) το επίπεδο ελέγχου έχει τρία κύρια εξαρτήματα: Pilot, Mixer, Citadel. Δεν θα εξετάσουμε το Citadel, είναι απαραίτητο να δημιουργήσουμε πιστοποιητικά για να διασφαλίσουμε το αμοιβαίο TLS μεταξύ των υπηρεσιών. Ας ρίξουμε μια πιο προσεκτική ματιά στη συσκευή και τον σκοπό του Pilot and Mixer.
Το Pilot είναι το κύριο στοιχείο ελέγχου που διανέμει όλες τις πληροφορίες σχετικά με το τι έχουμε στο σύμπλεγμα - υπηρεσίες, τα τελικά σημεία τους και κανόνες δρομολόγησης (για παράδειγμα, κανόνες για την ανάπτυξη Canary ή κανόνες διακόπτη κυκλώματος).
Το Mixer είναι ένα προαιρετικό στοιχείο επιπέδου ελέγχου που παρέχει τη δυνατότητα συλλογής μετρήσεων, αρχείων καταγραφής και οποιασδήποτε πληροφορίας σχετικά με την αλληλεπίδραση δικτύου. Παρακολουθεί επίσης τη συμμόρφωση με τους κανόνες Πολιτικής και τη συμμόρφωση με τα όρια τιμών.
Το επίπεδο δεδομένων υλοποιείται χρησιμοποιώντας κοντέινερ μεσολάβησης sidecar. Το Powerful χρησιμοποιείται από προεπιλογή. . Μπορεί να αντικατασταθεί από μια άλλη υλοποίηση, όπως το nginx (nginmesh).
Για να λειτουργεί το Istio απόλυτα διαφανές στις εφαρμογές, υπάρχει σύστημα αυτόματου ψεκασμού. Η πιο πρόσφατη υλοποίηση είναι κατάλληλη για εκδόσεις Kubernetes 1.9+ (mutational admission webhook). Για τις εκδόσεις 1.7, 1.8 του Kubernetes είναι δυνατή η χρήση του Initializer.
Τα κοντέινερ Sidecar συνδέονται στο Pilot χρησιμοποιώντας το πρωτόκολλο GRPC, το οποίο σας επιτρέπει να βελτιστοποιήσετε το μοντέλο push για αλλαγές που συμβαίνουν στο σύμπλεγμα. Το GRPC χρησιμοποιείται στο Envoy από την έκδοση 1.6, στο Istio χρησιμοποιείται από την έκδοση 0.8 και είναι ένας πιλότος-πράκτορας - ένα περιτύλιγμα golang πάνω από τον envoy που διαμορφώνει τις επιλογές εκκίνησης.
Το Pilot και το Mixer είναι εξαρτήματα εντελώς χωρίς κατάσταση, όλη η κατάσταση διατηρείται στη μνήμη. Η διαμόρφωση για αυτούς έχει οριστεί με τη μορφή προσαρμοσμένων πόρων Kubernetes, οι οποίοι αποθηκεύονται σε etcd.
Ο Istio-agent λαμβάνει τη διεύθυνση του πιλότου και ανοίγει μια ροή GRPC σε αυτόν.
Όπως είπα, το Istio υλοποιεί όλες τις λειτουργίες απόλυτα διαφανείς στις εφαρμογές. Ας δούμε πώς. Ο αλγόριθμος είναι αυτός:
- Ανάπτυξη μιας νέας έκδοσης της υπηρεσίας.
- Ανάλογα με την προσέγγιση έγχυσης κοντέινερ sidecar, το δοχείο istio-init και το δοχείο istio-agent (απεσταλμένος) προστίθενται στο στάδιο της εφαρμογής της διαμόρφωσης ή μπορούν ήδη να εισαχθούν χειροκίνητα στην περιγραφή της οντότητας Kubernetes Pod.
- Το κοντέινερ istio-init είναι ένα σενάριο που εφαρμόζει τους κανόνες iptables στο pod. Υπάρχουν δύο επιλογές για τη διαμόρφωση της κυκλοφορίας ώστε να είναι τυλιγμένη σε ένα κοντέινερ istio-agent: χρήση κανόνων ανακατεύθυνσης iptables ή . Κατά τη στιγμή της γραφής, η προεπιλεγμένη προσέγγιση είναι με κανόνες ανακατεύθυνσης. Στο istio-init, είναι δυνατό να ρυθμίσετε ποια κίνηση θα πρέπει να υποκλαπεί και να σταλεί στον istio-agent. Για παράδειγμα, για να παρακολουθήσετε όλη την εισερχόμενη και όλη την εξερχόμενη κίνηση, πρέπει να ορίσετε τις παραμέτρους
-iи-bσε νόημα*. Μπορείτε να καθορίσετε συγκεκριμένες θύρες για αναχαίτιση. Για να μην παρεμποδίσετε ένα συγκεκριμένο υποδίκτυο, μπορείτε να το καθορίσετε χρησιμοποιώντας τη σημαία-x. - Αφού εκτελεστούν τα κοντέινερ init, εκτοξεύονται τα κύρια, συμπεριλαμβανομένου του πιλότου-πράκτορα (απεσταλμένου). Συνδέεται με το ήδη αναπτυσσόμενο Pilot μέσω GRPC και λαμβάνει πληροφορίες για όλες τις υπάρχουσες υπηρεσίες και πολιτικές δρομολόγησης στο σύμπλεγμα. Σύμφωνα με τα δεδομένα που έλαβε, διαμορφώνει τα συμπλέγματα και τα εκχωρεί απευθείας στα τελικά σημεία των εφαρμογών μας στο σύμπλεγμα Kubernetes. Είναι επίσης απαραίτητο να σημειώσετε ένα σημαντικό σημείο: ο envoy ρυθμίζει δυναμικά τους ακροατές (IP, ζεύγη θυρών) που αρχίζει να ακούει. Επομένως, όταν τα αιτήματα εισέρχονται στο pod, ανακατευθύνονται χρησιμοποιώντας τους κανόνες ανακατεύθυνσης iptables στο sidecar, ο envoy μπορεί ήδη να επεξεργαστεί με επιτυχία αυτές τις συνδέσεις και να κατανοήσει πού να υποκαταστήσει περαιτέρω την κυκλοφορία. Επίσης, σε αυτό το στάδιο, αποστέλλονται πληροφορίες στο Mixer, το οποίο θα εξετάσουμε αργότερα, και αποστέλλονται διαστήματα ανίχνευσης.
Ως αποτέλεσμα, έχουμε ένα ολόκληρο δίκτυο διακομιστών μεσολάβησης envoy που μπορούμε να διαμορφώσουμε από ένα σημείο (Pilot). Όλα τα εισερχόμενα και εξερχόμενα αιτήματα περνούν μέσω απεσταλμένου. Επιπλέον, παρεμποδίζεται μόνο η κυκλοφορία TCP. Αυτό σημαίνει ότι η IP υπηρεσίας Kubernetes επιλύεται χρησιμοποιώντας kube-dns μέσω UDP χωρίς αλλαγή. Στη συνέχεια, μετά την επίλυση, το εξερχόμενο αίτημα υποκλαπεί και υποβάλλεται σε επεξεργασία από τον απεσταλμένο, ο οποίος ήδη αποφασίζει σε ποιο τελικό σημείο θα σταλεί το αίτημα (ή όχι, στην περίπτωση των πολιτικών πρόσβασης ή του διακόπτη κυκλώματος του αλγορίθμου).
Καταλάβαμε το Pilot, τώρα πρέπει να καταλάβουμε πώς λειτουργεί το Mixer και γιατί χρειάζεται. Μπορείτε να διαβάσετε την επίσημη τεκμηρίωση για αυτό .
Ο μίξερ στη σημερινή του μορφή αποτελείται από δύο στοιχεία: ιστιο-τηλεμετρία, ιστιο-πολιτική (πριν από την έκδοση 0.8 ήταν ένα εξάρτημα ιστιο-μίξερ). Και τα δύο είναι μίξερ, καθένα από τα οποία είναι υπεύθυνο για το δικό του έργο. Η τηλεμετρία Istio λαμβάνει πληροφορίες σχετικά με το ποιος πηγαίνει πού και με ποιες παραμέτρους από κοντέινερ αναφοράς sidecar μέσω GRPC. Η Istio-policy δέχεται αιτήματα ελέγχου για να επαληθεύσει ότι πληρούνται οι κανόνες πολιτικής. Οι έλεγχοι πολιτικής, φυσικά, δεν πραγματοποιούνται για κάθε αίτημα, αλλά αποθηκεύονται προσωρινά στον πελάτη (στο πλαϊνό καρό) για ορισμένο χρόνο. Οι έλεγχοι αναφορών αποστέλλονται ως αιτήματα παρτίδας. Ας δούμε πώς να ρυθμίσετε τις παραμέτρους και ποιες παράμετροι θα πρέπει να σταλούν λίγο αργότερα.
Το Mixer υποτίθεται ότι είναι ένα εξαιρετικά διαθέσιμο εξάρτημα που εξασφαλίζει αδιάλειπτη εργασία για τη συναρμολόγηση και την επεξεργασία δεδομένων τηλεμετρίας. Το σύστημα λαμβάνεται ως αποτέλεσμα ως buffer πολλαπλών επιπέδων. Αρχικά, τα δεδομένα αποθηκεύονται στην προσωρινή μνήμη στην πλευρά του sidecar των δοχείων, στη συνέχεια στην πλευρά του μίκτη και στη συνέχεια αποστέλλονται στα λεγόμενα backends του μίκτη. Ως αποτέλεσμα, εάν κάποιο από τα στοιχεία του συστήματος αποτύχει, το buffer μεγαλώνει και ξεπλένεται μετά την αποκατάσταση του συστήματος. Τα backend του Mixer είναι τελικά σημεία για την αποστολή δεδομένων τηλεμετρίας: statsd, newrelic, κ.λπ. Μπορείτε να γράψετε το δικό σας backend, είναι αρκετά απλό και θα δούμε πώς να το κάνουμε.
Συνοψίζοντας, το σχήμα εργασίας με την ιστιοτηλεμετρία είναι το εξής.
- Η υπηρεσία 1 στέλνει ένα αίτημα στην υπηρεσία 2.
- Όταν φεύγετε από την υπηρεσία 1, το αίτημα είναι τυλιγμένο στο δικό του πλευρικό καρότσι.
- Ο απεσταλμένος του Sidecar παρακολουθεί τον τρόπο με τον οποίο το αίτημα πηγαίνει στην υπηρεσία 2 και προετοιμάζει τις απαραίτητες πληροφορίες.
- Στη συνέχεια, το στέλνει στην istio-telemetry χρησιμοποιώντας ένα αίτημα αναφοράς.
- Η Ιστιο-τηλεμετρία καθορίζει εάν αυτή η Αναφορά θα πρέπει να σταλεί στα backends, σε ποια και ποια δεδομένα πρέπει να σταλούν.
- Η Istio-telemetry στέλνει δεδομένα αναφοράς στο backend εάν χρειάζεται.
Τώρα ας δούμε πώς να αναπτύξουμε το Istio στο σύστημα, που αποτελείται μόνο από τα κύρια στοιχεία (Pilot και sidecar envoy).
Αρχικά, ας δούμε την κύρια διαμόρφωση (πλέγμα) που διαβάζει ο 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
Όλα τα κύρια στοιχεία ελέγχου (επίπεδο ελέγχου) θα βρίσκονται στον χώρο ονομάτων istio-system στο Kubernetes.
Τουλάχιστον, χρειάζεται μόνο να αναπτύξουμε το Pilot. Για αυτό θα χρησιμοποιήσουμε
Και θα διαμορφώσουμε με μη αυτόματο τρόπο το πλευρικό κάλυμμα έγχυσης του δοχείου.
Δοχείο έναρξης:
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, οι περιγραφές των οποίων μπορείτε να βρείτε .
Ως αποτέλεσμα, η υπηρεσία στην οποία εισάγουμε το sidecar με απεσταλμένο θα πρέπει να ξεκινήσει με επιτυχία, να λάβει όλες τις ανακαλύψεις από τον πιλότο και να επεξεργαστεί αιτήματα.
Είναι σημαντικό να κατανοήσουμε ότι όλα τα στοιχεία του επιπέδου ελέγχου είναι εφαρμογές χωρίς κατάσταση και μπορούν να κλιμακωθούν οριζόντια χωρίς προβλήματα. Όλα τα δεδομένα αποθηκεύονται σε etcd με τη μορφή προσαρμοσμένων περιγραφών των πόρων Kubernetes.
Επίσης, το Istio (ακόμα πειραματικό) έχει τη δυνατότητα να τρέχει έξω από το σύμπλεγμα και τη δυνατότητα να παρακολουθεί και να ανακαλύπτει την υπηρεσία ανακάλυψης μεταξύ πολλών συμπλεγμάτων Kubernetes. Μπορείτε να διαβάσετε περισσότερα για αυτό .
Για εγκατάσταση πολλαπλών συστάδων, έχετε υπόψη σας τους ακόλουθους περιορισμούς:
- Το Pod CIDR και το Service CIDR πρέπει να είναι μοναδικά σε όλα τα συμπλέγματα και δεν πρέπει να επικαλύπτονται.
- Όλα τα CIDR Pods πρέπει να είναι προσβάσιμα από οποιοδήποτε CIDR Pods μεταξύ συμπλέγματος.
- Όλοι οι διακομιστές API Kubernetes πρέπει να είναι προσβάσιμοι μεταξύ τους.
Αυτές είναι οι αρχικές πληροφορίες που θα σας βοηθήσουν να ξεκινήσετε με το Istio. Ωστόσο, υπάρχουν ακόμα πολλές παγίδες. Για παράδειγμα, χαρακτηριστικά δρομολόγησης εξωτερικής κυκλοφορίας (έξω από το σύμπλεγμα), προσεγγίσεις για τον εντοπισμό σφαλμάτων sidecars, τη δημιουργία προφίλ, τη ρύθμιση ενός μίκτη και τη σύνταξη ενός προσαρμοσμένου backend μείκτη, τη ρύθμιση ενός μηχανισμού ανίχνευσης και τη λειτουργία του χρησιμοποιώντας envoy.
Όλα αυτά θα τα εξετάσουμε στις επόμενες δημοσιεύσεις. Κάντε τις ερωτήσεις σας, θα προσπαθήσω να τις καλύψω.
Πηγή: www.habr.com