Што е ? Ова е таканаречената Service mesh, технологија која додава слој на апстракција преку мрежата. Ние го пресретнуваме целиот или дел од сообраќајот во кластерот и извршуваме одреден сет на операции со него. Кое? На пример, правиме паметно рутирање или го имплементираме пристапот на прекинувачот, можеме да организираме „распоредување на канаринци“, делумно да го префрлиме сообраќајот на нова верзија на услугата или да ги ограничиме надворешните интеракции и да ги контролираме сите патувања од кластерот до надворешна мрежа. Можно е да се постават правила за политики за контрола на патувањата помеѓу различни микросервиси. Конечно, можеме да ја добиеме целата мапа на мрежна интеракција и да ја направиме унифицираната колекција на метрика целосно транспарентна за апликациите.
Можете да прочитате за механизмот на работа во . Istio е навистина моќна алатка која ви овозможува да решавате многу задачи и проблеми. Во оваа статија, би сакал да одговорам на главните прашања што обично се појавуваат при започнувањето со Istio. Ова ќе ви помогне побрзо да се справите со тоа.
Принцип на работа
Истио се состои од две главни области - контролната рамнина и рамнината на податоци. Контролната рамнина ги содржи главните компоненти кои обезбедуваат правилно функционирање на останатите. Во тековната верзија (1.0) контролниот авион има три главни компоненти: пилот, миксер, цитадела. Ние нема да ја разгледаме Цитадела, потребно е да се генерираат сертификати за да се обезбеди взаемна TLS помеѓу услугите. Да ги разгледаме подетално уредот и целта на Pilot and Mixer.
Пилот е главната контролна компонента која ги дистрибуира сите информации за она што го имаме во кластерот - услугите, нивните крајни точки и правилата за насочување (на пример, правила за распоредување на Канарските или правила за прекинувачот).
Миксерот е опционална компонента за контролна рамнина која обезбедува можност за собирање метрика, логови и какви било информации за мрежната интеракција. Тој, исто така, ја следи усогласеноста со правилата на Политика и усогласеноста со ограничувањата на стапките.
Рамнината на податоци се имплементира со помош на контејнери за прокси од страната. Моќното се користи стандардно. . Може да се замени со друга имплементација, како што е nginx (nginmesh).
За да може Istio да работи целосно транспарентно за апликациите, постои систем за автоматско вбризгување. Најновата имплементација е погодна за верзии на Kubernetes 1.9+ (мутациона веб-кука за прием). За верзиите 1.7, 1.8 на Kubernetes, можно е да се користи иницијализаторот.
Контејнерите на страничниот автомобил се поврзани со Pilot со помош на протоколот GRPC, кој ви овозможува да го оптимизирате моделот на туркање за промени што се случуваат во кластерот. GRPC се користи во Envoy од верзијата 1.6, во Istio се користи од верзијата 0.8 и е пилот-агент - обвивка за голанг над пратеникот што ги конфигурира опциите за лансирање.
Пилот и миксер се целосно компоненти без државјанство, целата состојба се чува во меморија. Конфигурацијата за нив е поставена во форма на Кубернетес прилагодени ресурси, кои се зачувани во итн.
Istio-agent ја добива адресата на пилотот и отвора проток на GRPC до него.
Како што реков, Istio ја имплементира целата функционалност целосно транспарентна за апликациите. Ајде да видиме како. Алгоритмот е овој:
- Распоредување на нова верзија на услугата.
- Во зависност од пристапот за вбризгување на контејнерот со странична кола, контејнерот istio-init и контејнерот за istio-агенс (претставник) се додаваат во фазата на примена на конфигурацијата, или тие веќе можат рачно да се вметнат во описот на ентитетот Kubernetes Pod.
- Контејнерот istio-init е скрипта што ги применува правилата iptables на подлогата. Постојат две опции за конфигурирање на сообраќајот да биде завиткан во контејнер за istio-агент: користете правила за пренасочување iptables, или . Во моментот на пишување, стандардниот пристап е со правила за пренасочување. Во istio-init, можно е да се конфигурира кој сообраќај треба да биде пресретнат и испратен до istio-agent. На пример, за да го пресретнете целиот дојдовен и целиот појдовен сообраќај, треба да ги поставите параметрите
-iи-bво значење*. Можете да наведете одредени порти за пресретнување. За да не пресретнете одредена подмрежа, можете да ја наведете користејќи го знамето-x. - Откако ќе се извршат инитните контејнери, се лансираат главните, вклучително и пилот-агентот (претставникот). Се поврзува со веќе распоредениот пилот преку GRPC и добива информации за сите постоечки услуги и политики за рутирање во кластерот. Според добиените податоци, тој ги конфигурира кластерите и ги доделува директно на крајните точки на нашите апликации во кластерот Kubernetes. Исто така, неопходно е да се забележи важна точка: пратеникот динамично ги конфигурира слушателите (IP, парови на порти) што почнува да ги слуша. Затоа, кога барањата влегуваат во подлогата, се пренасочуваат со користење на правилата за пренасочување iptables во страничната карта, претставникот веќе може успешно да ги обработува овие врски и да разбере каде понатаму да го замени сообраќајот. Исто така, во оваа фаза, информациите се испраќаат до миксерот, кои ќе ги разгледаме подоцна и се испраќаат распони за следење.
Како резултат на тоа, добиваме цела мрежа на прокси-сервери за испраќање што можеме да ги конфигурираме од една точка (Пилот). Сите влезни и излезни барања одат преку пратеник. Покрај тоа, само TCP сообраќајот е пресретнат. Ова значи дека ИП на услугата Kubernetes се решава со користење на kube-dns преку UDP без промена. Потоа, по решавањето, појдовното барање се пресретнува и се обработува од пратеник, кој веќе одлучува до која крајна точка барањето треба да се испрати (или да не се испрати, во случај на политики за пристап или прекинувач на колото на алгоритмот).
Го сфативме Пилот, сега треба да разбереме како работи Миксер и зошто е потребен. Можете да ја прочитате официјалната документација за тоа .
Миксерот во неговата сегашна форма се состои од две компоненти: истио-телеметрија, истио-политика (пред верзијата 0.8 беше една компонента на истио-мешалка). И двете се мешалки, од кои секоја е одговорна за својата задача. Телеметријата „Истио“ добива информации за тоа кој каде оди и со кои параметри од контејнерите за известување на страничната кола преку GRPC. Istio-policy прифаќа барања за проверка за да потврди дека правилата на политиката се задоволени. Политичките проверки, се разбира, не се вршат за секое барање, туку се кеширани на клиентот (во бочната кола) одредено време. Проверките на извештаите се испраќаат како сериски барања. Ајде да видиме како да конфигурираме и кои параметри треба да се испратат малку подоцна.
Миксерот треба да биде високо достапна компонента која обезбедува непречена работа на склопување и обработка на телеметриски податоци. Системот се добива како резултат како тампон на повеќе нивоа. Првично, податоците се меморираат на страничната страна на контејнерите, потоа на страната на миксер, а потоа се испраќаат до таканаречените задни делови на миксер. Како резултат на тоа, ако некоја од компонентите на системот не успее, тампонот расте и се испушта откако системот ќе се врати. Позадините на миксер се крајни точки за испраќање телеметриски податоци: statsd, newrelic итн. Можете да напишете свој заднина, тоа е прилично едноставно, и ќе видиме како да го направиме тоа.
Да резимираме, шемата за работа со истио-телеметрија е следна.
- Услугата 1 испраќа барање до услугата 2.
- Кога ја напуштате услугата 1, барањето е завиткано во сопствената бочна кола.
- Претставникот на Sidecar следи како барањето оди до службата 2 и ги подготвува потребните информации.
- Потоа го испраќа до istio-telemetry користејќи барање за извештај.
- Истио-телеметрија одредува дали овој Извештај треба да се испрати до бекендовите, до кои и кои податоци да се испраќаат.
- Istio-telemetry испраќа податоци за Извештај до задниот дел доколку е потребно.
Сега да видиме како да го распоредиме Istio во системот, кој се состои само од главните компоненти (Пилот и пратенички придружник).
Прво, да ја погледнеме главната конфигурација (мрежа) што ја чита Пилот:
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-систем во Kubernetes.
На минимум, треба само да распоредиме Пилот. За ова користиме
И ние рачно ќе го конфигурираме страничниот дел за инјектирање на контејнерот.
Почетен контејнер:
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, чии описи може да се најдат .
Како резултат на тоа, услугата во која ја вбризгуваме бочната кола со пратеник треба да започне успешно, да ги добие сите откритија од пилотот и да ги обработи барањата.
Важно е да се разбере дека сите компоненти на контролната рамнина се апликации без државјанство и можат да бидат хоризонтално размерени без проблеми. Сите податоци се чуваат во etcd во форма на прилагодени описи на ресурсите на Kubernetes.
Исто така, Istio (сè уште е експериментален) има способност да работи надвор од кластерот и способност да гледа и да го пробива откривањето на услугата помеѓу неколку кластери Кубернетес. Можете да прочитате повеќе за ова .
За инсталација со повеќе кластери, внимавајте на следните ограничувања:
- Pod CIDR и Service CIDR мора да бидат единствени во сите кластери и не смеат да се преклопуваат.
- Сите CIDR Pods мора да бидат достапни од кои било CIDR Pods помеѓу кластерите.
- Сите сервери на Kubernetes API мора да бидат достапни еден за друг.
Ова се првичните информации кои ќе ви помогнат да започнете со Istio. Сепак, сè уште има многу стапици. На пример, карактеристики на рутирање на надворешниот сообраќај (надвор од кластерот), пристапи за дебагирање на страничните картички, профилирање, поставување миксер и пишување прилагоден заднина на миксер, поставување механизам за следење и негово функционирање со помош на envoy.
Сето ова ќе го разгледаме во следните публикации. Поставете ги вашите прашања, ќе се обидам да ги опфатам.
Извор: www.habr.com