Не болды ? Бұл желі арқылы абстракция қабатын қосатын технология, Service mesh деп аталады. Біз кластердегі трафиктің барлығын немесе бір бөлігін ұстап аламыз және онымен белгілі бір операциялар жиынтығын орындаймыз. Дәл қайсысы? Мысалы, біз смарт маршруттауды жасаймыз немесе автоматты ажыратқыш тәсілін енгіземіз, біз трафикті қызметтің жаңа нұсқасына ішінара ауыстыра отырып, «канарларды орналастыруды» ұйымдастыра аламыз немесе сыртқы өзара әрекеттесуді шектей аламыз және кластерден кластерге дейінгі барлық сапарларды басқара аламыз. сыртқы желі. Әртүрлі микросервистер арасындағы сапарларды басқару үшін саясат ережелерін орнатуға болады. Соңында, біз бүкіл желілік өзара әрекеттесу картасын ала аламыз және өлшемдердің біртұтас жинағын қолданбалар үшін толығымен мөлдір ете аламыз.
Сіз жұмыс механизмі туралы оқи аласыз . Istio - көптеген тапсырмалар мен мәселелерді шешуге мүмкіндік беретін шынымен қуатты құрал. Бұл мақалада мен әдетте Istio-мен жұмысты бастаған кезде туындайтын негізгі сұрақтарға жауап бергім келеді. Бұл сізге онымен тезірек күресуге көмектеседі.
Жұмыс принципі
Istio екі негізгі аймақтан тұрады - басқару жазықтығы және деректер жазықтығы. Басқару жазықтығы қалған бөліктердің дұрыс жұмысын қамтамасыз ететін негізгі компоненттерді қамтиды. Ағымдағы нұсқада (1.0) басқару ұшағында үш негізгі компонент бар: Пилот, Миксер, Цитадель. Біз Citadel-ті қарастырмаймыз, қызметтер арасында өзара TLS қамтамасыз ету үшін сертификаттарды жасау қажет. Pilot and Mixer құрылғысы мен мақсатын толығырақ қарастырайық.
Пилот - бұл кластерде бар нәрселер туралы барлық ақпаратты тарататын негізгі басқару құрамдас бөлігі - қызметтер, олардың соңғы нүктелері және маршруттау ережелері (мысалы, Canary орналастыру ережелері немесе автоматты ажыратқыш ережелері).
Миксер – метриканы, журналдарды және желілік өзара әрекеттесу туралы кез келген ақпаратты жинау мүмкіндігін қамтамасыз ететін қосымша басқару жазықтығы құрамдас бөлігі. Ол сондай-ақ Саясат ережелерінің сақталуын және тарифтік шектеулердің сақталуын бақылайды.
Деректер жазықтығы бүйірлік прокси-контейнерлердің көмегімен жүзеге асырылады. Powerful әдепкі бойынша пайдаланылады. . Оны nginx (nginmesh) сияқты басқа іске асырумен ауыстыруға болады.
Istio қолданбаларға толығымен мөлдір жұмыс істеуі үшін автоматты бүрку жүйесі бар. Соңғы енгізу Kubernetes 1.9+ нұсқалары үшін жарамды (мутациялық қабылдау веб-хук). Kubernetes 1.7, 1.8 нұсқалары үшін инициализаторды пайдалануға болады.
Бүйірлік контейнерлер GRPC протоколы арқылы Pilot бағдарламасына қосылған, бұл кластерде орын алатын өзгерістер үшін push үлгісін оңтайландыруға мүмкіндік береді. GRPC Envoy бағдарламасында 1.6 нұсқасынан бастап, Istio бағдарламасында 0.8 нұсқасынан бері қолданылған және ұшқыш-агент болып табылады - іске қосу опцияларын конфигурациялайтын елшіге арналған голанг орауыш.
Пилот пен Миксер толығымен азаматтығы жоқ құрамдас болып табылады, барлық күй жадта сақталады. Оларға арналған конфигурация etcd ішінде сақталған Kubernetes пайдаланушы ресурстары түрінде орнатылған.
Istio-агент ұшқыштың мекенжайын алады және оған GRPC ағынын ашады.
Мен айтқанымдай, Istio қолданбалар үшін толығымен мөлдір барлық функцияларды жүзеге асырады. Қалай көрейік. Алгоритм бұл:
- Қызметтің жаңа нұсқасын қолдану.
- Бүйірлік контейнерді инъекциялау тәсіліне байланысты istio-init контейнері және istio-агент контейнері (елші) конфигурацияны қолдану сатысында қосылады немесе оларды Kubernetes Pod нысанының сипаттамасына қолмен енгізуге болады.
- istio-init контейнері iptables ережелерін подкастқа қолданатын сценарий болып табылады. Istio-агент контейнеріне оралатын трафикті теңшеудің екі нұсқасы бар: iptables қайта бағыттау ережелерін пайдаланыңыз немесе . Жазу кезінде әдепкі әдіс қайта бағыттау ережелері болып табылады. istio-init ішінде қай трафикті ұстап алып, istio-агентке жіберу керектігін конфигурациялауға болады. Мысалы, барлық кіріс және шығыс трафикті ұстап тұру үшін параметрлерді орнату керек
-iи-bмағынаға*. Сіз ұстайтын арнайы порттарды көрсете аласыз. Белгілі бір ішкі желіні ұстап алмау үшін оны жалауша арқылы көрсетуге болады-x. - Init контейнерлері орындалғаннан кейін негізгілері іске қосылады, оның ішінде пилот-агент (елші). Ол GRPC арқылы бұрыннан орналастырылған Пилотқа қосылып, кластердегі барлық бар қызметтер мен маршруттау саясаттары туралы ақпаратты алады. Алынған деректерге сәйкес, ол кластерлерді конфигурациялайды және оларды тікелей Kubernetes кластеріндегі қолданбаларымыздың соңғы нүктелеріне тағайындайды. Сондай-ақ маңызды жайтты атап өту қажет: өкіл тыңдай бастайтын тыңдаушыларды (IP, порт жұптары) динамикалық түрде конфигурациялайды. Сондықтан, сұраулар подключке кіргенде, бүйірлік вагондағы қайта бағыттау iptables ережелері арқылы қайта бағытталса, өкіл осы қосылымдарды сәтті өңдей алады және трафикті әрі қарай қайда проксилеу керектігін түсінеді. Сондай-ақ осы кезеңде Миксерге ақпарат жіберіледі, біз оны кейінірек қарастырамыз және трассалар жіберіледі.
Нәтижесінде біз бір нүктеден конфигурациялай алатын өкіл прокси серверлерінің бүкіл желісін аламыз (Пилот). Барлық кіріс және шығыс сұраулар өкіл арқылы өтеді. Сонымен қатар, тек TCP трафигі ұсталады. Бұл Kubernetes қызметінің IP мекенжайы өзгертілмей UDP арқылы kube-dns арқылы шешілетінін білдіреді. Содан кейін, шешілгеннен кейін, шығыс сұрауды елші ұстайды және өңдейді, ол сұрауды қай соңғы нүктеге жіберу керектігін шешеді (немесе рұқсат саясаттары немесе алгоритмнің автоматты ажыратқышы жағдайында жіберілмейді).
Біз Пилотты анықтадық, енді Миксердің қалай жұмыс істейтінін және оның не үшін қажет екенін түсінуіміз керек. Ол үшін ресми құжаттаманы оқуға болады .
Миксер қазіргі түрінде екі компоненттен тұрады: истио-телеметрия, истио-политика (0.8 нұсқасына дейін ол бір истио-миксер компоненті болған). Олардың екеуі де араластырғыштар, олардың әрқайсысы өз міндетіне жауап береді. Istio телеметриясы GRPC арқылы бүйірлік есеп контейнерлерінен кім қайда және қандай параметрлермен баратыны туралы ақпаратты алады. Istio-policy саясаты ережелерінің қанағаттандырылғанын тексеру үшін тексеру сұрауларын қабылдайды. Политика тексерулері, әрине, әрбір сұрау үшін жүргізілмейді, бірақ белгілі бір уақыт ішінде клиентте (серверде) кэштеледі. Есеп тексерулері пакеттік сұраулар ретінде жіберіледі. Қалай конфигурациялау керектігін және қандай параметрлерді сәл кейінірек жіберу керектігін көрейік.
Миксер телеметрия деректерін жинау және өңдеу бойынша үзіліссіз жұмысты қамтамасыз ететін жоғары қолжетімді құрамдас болуы керек. Жүйе нәтижесінде көп деңгейлі буфер алынады. Бастапқыда деректер контейнерлердің бүйір жағында, содан кейін араластырғыш жағында буферленеді, содан кейін араластырғыштың артқы жағы деп аталатындарға жіберіледі. Нәтижесінде жүйе құрамдастарының кез келгені сәтсіз болса, буфер үлкейеді және жүйе қалпына келтірілгеннен кейін тазартылады. Миксер серверлері телеметрия деректерін жіберуге арналған соңғы нүктелер болып табылады: statsd, newrelic және т.б. Сіз өзіңіздің серверіңізді жаза аласыз, бұл өте қарапайым және оны қалай жасау керектігін көреміз.
Қорытындылай келе, истио-телеметриямен жұмыс істеу схемасы келесідей.
- 1-сервис 2-сервиске сұраныс жібереді.
- 1-қызметтен шыққан кезде сұрау өзінің бүйірлік қалтасына оралады.
- Sidecar өкілі сұраудың 2-сервиске қалай түсетінін бақылайды және қажетті ақпаратты дайындайды.
- Содан кейін оны Есеп сұрауы арқылы истио-телеметрияға жібереді.
- Istio-телеметрия бұл Есепті серверлерге жіберу керек пе, қайсысына және қандай деректер жіберілу керектігін анықтайды.
- Istio-temetry қажет болса, есеп деректерін серверге жібереді.
Енді тек негізгі құрамдас бөліктерден тұратын жүйеде 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
Барлық негізгі басқару құрамдастары (басқару жазықтығы) Kubernetes ішіндегі аттар кеңістігі istio-жүйесінде орналасады.
Кем дегенде, бізге тек Пилотты орналастыру керек. Ол үшін біз пайдаланамыз
Біз контейнердің инъекциялық жағын қолмен конфигурациялаймыз.
Бастапқы контейнер:
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 жасау керек, олардың сипаттамасын табуға болады. .
Нәтижесінде, біз елші бар бүйір вагонды енгізетін қызмет сәтті басталып, пилоттан барлық ашылымды алып, сұрауларды өңдеуі керек.
Басқару жазықтығының барлық құрамдастары азаматтығы жоқ қолданбалар болып табылатынын және оларды көлденеңінен ақаусыз масштабтауға болатындығын түсіну маңызды. Барлық деректер etcd ішінде Kubernetes ресурстарының реттелетін сипаттамалары түрінде сақталады.
Сондай-ақ, Istio (әлі де эксперименталды) кластерден тыс жұмыс істеу мүмкіндігіне және бірнеше Kubernetes кластерлері арасында қызмет ашуын көру және бұзу мүмкіндігіне ие. Бұл туралы толығырақ оқуға болады .
Көп кластерді орнату үшін келесі шектеулерді ескеріңіз:
- Pod CIDR және Service CIDR барлық кластерлерде бірегей болуы керек және бір-біріне сәйкес келмеуі керек.
- Барлық CIDR қосқыштары кластерлер арасындағы кез келген CIDR Pod құрылғыларынан қолжетімді болуы керек.
- Барлық Kubernetes API серверлері бір-біріне қолжетімді болуы керек.
Бұл Istio қолданбасын бастауға көмектесетін бастапқы ақпарат. Дегенмен, әлі де көптеген тұзақтар бар. Мысалы, сыртқы трафикті (кластерден тыс) бағыттау мүмкіндіктері, жанамаларды жөндеу тәсілдері, профильдеу, араластырғышты орнату және реттелетін араластырғыш серверін жазу, бақылау механизмін орнату және оның envoy көмегімен жұмыс істеуі.
Мұның бәрін біз келесі басылымдарда қарастырамыз. Сұрақтарыңызды қойыңыздар, мен оларды қамтуға тырысамын.
Ақпарат көзі: www.habr.com