гэж юу вэ ? Энэ бол Service mesh гэж нэрлэгддэг технологи бөгөөд сүлжээгээр хийсвэрлэх давхаргыг нэмдэг технологи юм. Бид кластер дахь урсгалыг бүхэлд нь эсвэл хэсэгчлэн таслан зогсоож, түүнтэй тодорхой багц үйлдлийг гүйцэтгэдэг. Аль нь? Жишээлбэл, бид ухаалаг чиглүүлэлт хийдэг, эсвэл таслагчийн хандлагыг хэрэгжүүлдэг, бид "канарын байршуулалт" зохион байгуулж, траффикийг үйлчилгээний шинэ хувилбар руу хэсэгчлэн шилжүүлж болно, эсвэл бид гадны харилцан үйлчлэлийг хязгаарлаж, кластераас бүх аялалыг хянах боломжтой. гадаад сүлжээ. Янз бүрийн микро үйлчилгээнүүдийн хоорондох аяллыг хянах бодлогын дүрмийг тохируулах боломжтой. Эцэст нь бид сүлжээний харилцан үйлчлэлийн газрын зургийг бүхэлд нь авч, хэмжүүрүүдийн нэгдсэн цуглуулгыг програмуудад бүрэн ил тод болгож чадна.
Та ажлын механизмын талаар уншиж болно . Istio бол олон ажил, асуудлыг шийдвэрлэх боломжийг олгодог үнэхээр хүчирхэг хэрэгсэл юм. Энэ нийтлэлд би Istio-г ашиглаж эхлэхэд ихэвчлэн гарч ирдэг гол асуултуудад хариулахыг хүсч байна. Энэ нь танд үүнийг хурдан шийдвэрлэхэд тусална.
Хэрхэн ажилладаг
Istio нь хяналтын хавтгай ба мэдээллийн хавтгай гэсэн хоёр үндсэн хэсгээс бүрдэнэ. Хяналтын хавтгай нь үлдсэн хэсгийн зөв ажиллагааг хангах үндсэн бүрэлдэхүүн хэсгүүдийг агуулдаг. Одоогийн хувилбарт (1.0) хяналтын онгоц нь Pilot, Mixer, Citadel гэсэн гурван үндсэн бүрэлдэхүүн хэсэгтэй. Бид Citadel-ийг авч үзэхгүй, үйлчилгээний хооронд харилцан TLS баталгаажуулахын тулд гэрчилгээ үүсгэх шаардлагатай. Pilot and Mixer-ийн төхөөрөмж, зорилгыг нарийвчлан авч үзье.
Нисгэгч нь кластерт байгаа бүх мэдээллийг түгээдэг хяналтын гол бүрэлдэхүүн хэсэг юм - үйлчилгээ, тэдгээрийн төгсгөлийн цэгүүд, чиглүүлэлтийн дүрмүүд (жишээлбэл, Канарын байршуулалтын дүрэм эсвэл хэлхээ таслагчийн дүрмүүд).
Холигч нь хэмжигдэхүүн, лог болон сүлжээний харилцан үйлчлэлийн талаарх аливаа мэдээллийг цуглуулах боломжийг олгодог хяналтын онгоцны нэмэлт бүрэлдэхүүн хэсэг юм. Тэрээр мөн Бодлогын дүрмийг дагаж мөрдөх, тарифын хязгаарлалтыг дагаж мөрдөхөд хяналт тавьдаг.
Өгөгдлийн онгоцыг хажуугийн прокси контейнер ашиглан хэрэгжүүлдэг. Powerful-г анхдагчаар ашигладаг. . Үүнийг nginx (nginmesh) гэх мэт өөр хэрэглүүрээр сольж болно.
Istio нь програмуудад бүрэн ил тод ажиллахын тулд автомат тарилгын систем байдаг. Хамгийн сүүлийн хувилбар нь Kubernetes 1.9+ хувилбаруудад тохиромжтой (мутацийн элсэлтийн вэб дэгээ). Kubernetes 1.7, 1.8 хувилбаруудын хувьд эхлүүлэгчийг ашиглах боломжтой.
Хажуугийн савнууд нь GRPC протоколыг ашиглан Pilot-д холбогдсон бөгөөд энэ нь кластерт гарсан өөрчлөлтөд түлхэх загварыг оновчтой болгох боломжийг олгодог. GRPC нь Envoy-д 1.6 хувилбараас хойш, Istio-д 0.8 хувилбараас хойш ашиглагдаж байгаа бөгөөд нисгэгч-агент буюу хөөргөх сонголтыг тохируулдаг golang ороосон элч юм.
Pilot болон Mixer нь бүрэн харьяалалгүй бүрэлдэхүүн хэсгүүд бөгөөд бүх төлөв нь санах ойд хадгалагддаг. Тэдгээрийн тохиргоог etcd-д хадгалагдсан Kubernetes Custom Resources хэлбэрээр тохируулсан болно.
Istio-агент Нисгэгчийн хаягийг авч, GRPC урсгалыг нээнэ.
Миний хэлсэнчлэн, Istio бүх функцийг програмуудад бүрэн ил тод байдлаар хэрэгжүүлдэг. Хэрхэн гэдгийг харцгаая. Алгоритм нь дараах байдалтай байна.
- Үйлчилгээний шинэ хувилбарыг нэвтрүүлж байна.
- Хажуугийн савны савыг шахах аргаас хамааран istio-init контейнер болон istio-агент сав (элч) нь тохиргоог хэрэгжүүлэх үе шатанд нэмэгдэх эсвэл тэдгээрийг Kubernetes Pod нэгжийн тайлбарт гараар оруулах боломжтой.
- istio-init контейнер нь iptables дүрмийг pod-д хэрэглэх скрипт юм. Хөдөлгөөнийг istio-agent контейнерт оруулах хоёр сонголт байдаг: iptables дахин чиглүүлэх дүрмийг ашиглах эсвэл . Бичиж байх үед анхдагч арга нь дахин чиглүүлэх дүрмүүд юм. istio-init-д ямар урсгалыг саатуулж, istio-agent руу илгээхийг тохируулах боломжтой. Жишээлбэл, ирж буй болон гарч буй бүх урсгалыг таслан зогсоохын тулд та параметрүүдийг тохируулах хэрэгтэй
-iи-bутга руу оруулна*. Та таслах тусгай портуудыг зааж өгч болно. Тодорхой дэд сүлжээг саатуулахгүйн тулд туг ашиглан зааж өгч болно-x. - Init контейнеруудыг ажиллуулсны дараа нисгэгч-агент (элч төлөөлөгч) зэрэг голуудыг нь ажиллуулна. Энэ нь GRPC-ээр дамжуулан аль хэдийн байрлуулсан Pilot-той холбогдож, кластерт байгаа бүх үйлчилгээ болон чиглүүлэлтийн бодлогын талаарх мэдээллийг хүлээн авдаг. Хүлээн авсан өгөгдлүүдийн дагуу тэрээр кластеруудыг тохируулж, Кубернетес кластер дахь манай програмуудын төгсгөлийн цэгүүдэд шууд хуваарилдаг. Мөн нэг чухал зүйлийг тэмдэглэх нь зүйтэй: элч нь сонсож эхлэх сонсогчдыг (IP, порт хос) динамикаар тохируулдаг. Тиймээс, хүсэлтүүд нь подонд орж, хажуугийн тэрэгний iptables дүрмийн дагуу дахин чиглүүлэгдэх үед элч эдгээр холболтыг амжилттай боловсруулж, траффикийг хааш нь шилжүүлэхээ ойлгох боломжтой. Мөн энэ үе шатанд мэдээллийг холигч руу илгээдэг бөгөөд бид үүнийг дараа нь авч үзэх бөгөөд мөрийн зайг илгээдэг.
Үүний үр дүнд бид нэг цэгээс тохируулах боломжтой элч прокси серверүүдийн бүхэл бүтэн сүлжээг авдаг (Нисгэгч). Ирж буй болон гарч буй бүх хүсэлт элчээр дамждаг. Түүнээс гадна зөвхөн TCP урсгалыг саатуулдаг. Энэ нь Kubernetes үйлчилгээний IP-г өөрчлөхгүйгээр UDP дээр kube-dns ашиглан шийддэг гэсэн үг юм. Дараа нь шийдвэрлэсний дараа гарч буй хүсэлтийг элч таслан авч боловсруулдаг бөгөөд энэ нь хүсэлтийг аль төгсгөлийн цэг рүү илгээхийг шийддэг (эсвэл хандалтын бодлого эсвэл алгоритмын таслагчийн хувьд илгээхгүй).
Бид Pilot-ийг олж мэдсэн, одоо Mixer хэрхэн ажилладаг, яагаад хэрэгтэй байгааг ойлгох хэрэгтэй. Та албан ёсны баримт бичгийг уншиж болно .
Холигч нь одоогийн хэлбэрээрээ хоёр бүрэлдэхүүн хэсгээс бүрдэнэ: istio-telemetry, istio-policy (0.8 хувилбараас өмнө энэ нь нэг istio-холигч бүрэлдэхүүн хэсэг байсан). Эдгээр нь хоёулаа холигч бөгөөд тус бүр нь өөрийн ажлыг хариуцдаг. Istio telemetry нь GRPC-ээр дамжуулан хажуугийн тэрэгний Report контейнерээс хэн хаана, ямар параметрээр явж байгаа талаарх мэдээллийг хүлээн авдаг. Istio-policy нь Бодлогын дүрмүүд хангагдсан эсэхийг шалгах хүсэлтийг хүлээн авдаг. Бодлогын шалгалт нь мэдээжийн хэрэг хүсэлт бүрт хийгддэггүй, гэхдээ тодорхой хугацаанд үйлчлүүлэгч (хажуугийн тэрэг) дээр хадгалагддаг. Тайлангийн шалгалтыг багцын хүсэлтээр илгээдэг. Хэрхэн тохируулах, ямар параметрүүдийг илгээх ёстойг хэсэг хугацааны дараа харцгаая.
Холигч нь телеметрийн өгөгдлийг угсрах, боловсруулахад тасралтгүй ажиллах боломжийг олгодог өндөр боломжтой бүрэлдэхүүн хэсэг байх ёстой. Үүний үр дүнд системийг олон түвшний буфер болгон олж авдаг. Эхлээд өгөгдлийг савны хажуугийн хажуу талд, дараа нь холигч тал дээр буфер хийж, дараа нь холигч гэж нэрлэгддэг арын хэсэг рүү илгээдэг. Үүний үр дүнд системийн бүрэлдэхүүн хэсгүүдийн аль нэг нь бүтэлгүйтсэн тохиолдолд буфер нэмэгдэж, системийг сэргээсний дараа угаана. Холигч арын хэсэг нь телеметрийн өгөгдлийг илгээх төгсгөлийн цэгүүд юм: statsd, newrelic гэх мэт. Та өөрийн backend бичиж болно, энэ нь маш энгийн бөгөөд бид үүнийг хэрхэн хийхийг харах болно.
Дүгнэж хэлэхэд, истио-телеметритэй ажиллах схем дараах байдалтай байна.
- 1-р үйлчилгээ 2-р үйлчилгээ рүү хүсэлт илгээдэг.
- Үйлчилгээ 1-ээс гарахдаа хүсэлтийг өөрийн хажуугийн хайрцагт боож өгнө.
- Хажуугийн элч нь хүсэлт 2-р үйлчилгээнд хэрхэн очиж байгааг хянаж, шаардлагатай мэдээллийг бэлтгэдэг.
- Дараа нь Report хүсэлтийг ашиглан istio-temetry руу илгээнэ.
- Istio-temetry нь энэхүү тайланг арын хэсэгт илгээх эсэх, аль нь, ямар өгөгдөл илгээхийг тодорхойлдог.
- Istio-temetry нь шаардлагатай бол тайлангийн өгөгдлийг backend руу илгээдэг.
Одоо зөвхөн үндсэн бүрэлдэхүүн хэсгүүдээс (Нисгэгч ба хажуугийн элч) бүрдэх Istio-г системд хэрхэн байрлуулахыг харцгаая.
Эхлээд 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
Бүх үндсэн хяналтын бүрэлдэхүүн хэсгүүд (хяналтын хавтгай) Кубернетес дэх нэрийн талбарт байрлах болно.
Наад зах нь бид зөвхөн 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, Pilot-д зориулсан CRD үүсгэх хэрэгтэй бөгөөд тэдгээрийн тайлбарыг олж болно. .
Үүний үр дүнд элчтэй хамт хажуугийн тэрэг шахах үйлчилгээ амжилттай эхэлж, туршилтын бүх нээлтийг хүлээн авч, хүсэлтийг боловсруулах ёстой.
Хяналтын онгоцны бүх бүрэлдэхүүн хэсгүүд нь харьяалалгүй программууд бөгөөд ямар ч асуудалгүйгээр хэвтээ байдлаар масштаблах боломжтой гэдгийг ойлгох нь чухал юм. Бүх өгөгдлийг Kubernetes нөөцийн тусгай тайлбар хэлбэрээр etcd-д хадгалдаг.
Түүнчлэн, Istio (туршилтын хэвээр байгаа) нь кластераас гадуур ажиллах чадвартай бөгөөд хэд хэдэн Kubernetes кластеруудын хооронд үйлчилгээний нээлтийг ажиглаж, төөрөлдүүлэх чадвартай. Та энэ талаар илүү ихийг уншиж болно .
Олон кластер суулгахын тулд дараах хязгаарлалтыг анхаарч үзээрэй.
- Pod CIDR болон Service CIDR нь бүх кластерт өвөрмөц байх ёстой бөгөөд давхцаж болохгүй.
- Бүх CIDR Pod-д кластер хоорондын дурын CIDR Pod-оос хандах боломжтой байх ёстой.
- Бүх Kubernetes API серверүүд бие биедээ хандах боломжтой байх ёстой.
Энэ бол Istio-г эхлүүлэхэд туслах анхны мэдээлэл юм. Гэсэн хэдий ч олон бэрхшээл байсаар байна. Жишээлбэл, гадаад урсгалыг чиглүүлэх онцлог (кластерын гадна), хажуугийн машиныг дибаг хийх арга барил, профайл хийх, холигч тохируулах болон захиалгат холигч арын хэсгийг бичих, мөрдөх механизмыг тохируулах, элч ашиглан түүний ажиллагаа.
Энэ бүгдийг бид дараагийн хэвлэлд авч үзэх болно. Асуултаасаа асуугаарай, би тэдгээрийг хамрахыг хичээх болно.
Эх сурвалж: www.habr.com