Эмне болду ? Бул тармактын үстүнө абстракция катмарын кошкон технология деп аталган Кызматтык тор. Биз кластердеги трафиктин баарын же бир бөлүгүн кармайбыз жана аны менен белгилүү бир операцияларды аткарабыз. Кайсынысы? Мисалы, биз акылдуу маршрутту жасайбыз же автоматтык өчүргүч ыкмасын ишке ашырабыз, биз трафикти жарым-жартылай кызматтын жаңы версиясына которуштурууну уюштура алабыз, же тышкы өз ара аракеттенүүнү чектей алабыз жана кластерден бардык сапарларды көзөмөлдөй алабыз. тышкы тармак. Ар кандай микросервистердин ортосундагы сапарларды көзөмөлдөө үчүн саясат эрежелерин коюуга болот. Акыр-аягы, биз тармактын өз ара аракеттенүү картасын толугу менен ала алабыз жана метрикалардын бирдиктүү жыйнагын тиркемелер үчүн толугу менен ачык-айкын кыла алабыз.
Сиз иш механизми жөнүндө окуй аласыз . Istio - бул көптөгөн милдеттерди жана көйгөйлөрдү чечүүгө мүмкүндүк берген чындап күчтүү курал. Бул макалада мен Istio менен иштөөнү баштоодо пайда болгон негизги суроолорго жооп бергим келет. Бул сизге аны менен тезирээк күрөшүүгө жардам берет.
Иштөө принциби
Istio эки негизги аймактан турат - башкаруу тегиздиги жана маалымат тегиздиги. Башкаруу тегиздигинде калгандардын туура иштешин камсыз кылуучу негизги тетиктер бар. Учурдагы версияда (1.0) башкаруу учагы үч негизги компоненттен турат: Pilot, Mixer, Citadel. Биз Citadel каралбайбыз, ал кызматтардын ортосунда өз ара TLS камсыз кылуу үчүн сертификаттарды түзүү керек. Келгиле, Pilot and Mixerтин түзүлүшүн жана максатын кененирээк карап чыгалы.
Пилот - бул кластерде бизде болгон бардык маалыматты таратуучу негизги башкаруу компоненти - кызматтар, алардын акыркы чекиттери жана маршруттоо эрежелери (мисалы, Canary жайгаштыруу эрежелери же автоматтык өчүрүү эрежелери).
Миксер - бул метрикаларды, журналдарды жана тармактын өз ара аракеттенүүсү жөнүндө ар кандай маалыматты чогултуу мүмкүнчүлүгүн камсыз кылган кошумча башкаруу тегиздик компоненти. Ал ошондой эле Саясат эрежелеринин сакталышын жана тарифтик чектөөлөрдүн сакталышын көзөмөлдөйт.
Маалымат учагы каптал прокси контейнерлерин колдонуу менен ишке ашырылат. Powerful демейки боюнча колдонулат. . Аны башка ишке ашыруу менен алмаштырса болот, мисалы nginx (nginmesh).
Istio колдонмолорго толугу менен ачык-айкын иштеши үчүн, автоматтык сайынуу системасы бар. Акыркы ишке ашыруу Kubernetes 1.9+ версияларына ылайыктуу (мутациялык кирүү вебхуку). Kubernetes 1.7, 1.8 версиялары үчүн инициализаторду колдонсо болот.
Каптал контейнерлери Пилотко GRPC протоколунун жардамы менен туташтырылган, ал кластерде болуп жаткан өзгөрүүлөр үчүн түртүү моделин оптималдаштырууга мүмкүндүк берет. GRPC Envoyдо 1.6 версиясынан бери колдонулуп келет, Istio версиясында ал 0.8 версиясынан бери колдонулуп келет жана учкуч-агент - ишке киргизүү параметрлерин конфигурациялаган элчи үстүнөн голанг орогуч.
Пилот жана Миксер толугу менен жарандыгы жок компоненттер, бардык абал эс тутумда сакталат. Алар үчүн конфигурация etcd сакталган Kubernetes Custom Resources түрүндө орнотулган.
Istio-агент Пилоттун дарегин алат жана ага GRPC агымын ачат.
Мен айткандай, Istio бардык функцияларды тиркемелер үчүн ачык-айкын ишке ашырат. Келгиле, кантип карап көрөлү. Алгоритм бул:
- Кызматтын жаңы версиясын жайылтуу.
- Каптал контейнерин инъекциялоо ыкмасына жараша istio-init контейнери жана istio-агент контейнери (элчи) конфигурацияны колдонуу стадиясында кошулат же алар Kubernetes Pod объектинин сүрөттөмөсүнө мурунтан эле кол менен киргизилиши мүмкүн.
- İstio-init контейнери - бул iptables эрежелерин подкетке колдонуучу скрипт. İstio-агенттин контейнерине оролгон трафикти конфигурациялоонун эки варианты бар: iptables багыттоо эрежелерин колдонуңуз же . жазуу учурунда, демейки ыкма кайра багыттоо эрежелери менен болуп саналат. istio-initте, кайсы трафикти кармап, istio-агентке жөнөтүү керектигин конфигурациялоого болот. Мисалы, бардык кирүүчү жана бардык чыгуучу трафикти кармоо үчүн сиз параметрлерди коюшуңуз керек
-iи-bмааниге*. Сиз тосууга атайын портторду белгилей аласыз. Белгилүү бир ички тармакты кармап калбоо үчүн, аны желектин жардамы менен көрсөтсөңүз болот-x. - Init контейнерлери аткарылгандан кийин негизгилери, анын ичинде учкуч-агент (элчи) ишке киргизилет. Ал буга чейин орнотулган Пилотко GRPC аркылуу туташып, кластердеги бардык учурдагы кызматтар жана маршруттук саясаттар тууралуу маалыматты алат. Алынган маалыматтарга ылайык, ал кластерлерди конфигурациялайт жана аларды түздөн-түз Kubernetes кластериндеги тиркемелерибиздин акыркы чекиттерине дайындайт. Ошондой эле бир маанилүү жагдайды белгилей кетүү керек: элчи динамикалык түрдө уга баштаган угуучуларды (IP, порт жуптары) конфигурациялайт. Ошондуктан, суроо-талаптар подкастка киргенде, капталдагы кайра багыттоо iptables эрежелери аркылуу кайра багытталса, элчи бул байланыштарды ийгиликтүү иштетип, трафикти андан ары кайда прокси менен өткөрүүнү түшүнө алат. Ошондой эле бул этапта Миксерге маалымат жөнөтүлөт, биз аны кийинчерээк карап чыгабыз жана трассалар жөнөтүлөт.
Натыйжада, биз бир чекиттен конфигурациялай турган элчи прокси серверлеринин бүтүндөй тармагын алабыз (Пилот). Бардык кирүүчү жана чыгуучу суроо-талаптар элчи аркылуу өтөт. Мындан тышкары, бир гана TCP трафиги токтотулат. Бул Kubernetes кызмат IP өзгөрүүсүз UDP аркылуу kube-dns аркылуу чечилет дегенди билдирет. Андан кийин, чечилгенден кийин, чыгуучу суроо-талап элчи тарабынан кармалып, иштетилет, ал сурам кайсы акыркы чекитке жөнөтүлүшү керек экенин чечет (же кирүү саясаттары же алгоритмдин өчүргүчтөрү учурда жөнөтүлбөйт).
Биз Пилотту түшүндүк, эми Миксер кантип иштээрин жана ал эмне үчүн керек экенин түшүнүшүбүз керек. Ал үчүн расмий документтерди окуй аласыз .
Миксер азыркы түрүндө эки компоненттен турат: истио-телеметрия, истио-политика (0.8 версиясына чейин бул бир истио-миксер компоненти болгон). Экөө тең аралаштыргыч, алардын ар бири өз милдетине жооп берет. Istio телеметриясы GRPC аркылуу капталдагы Report контейнерлерден ким кайда жана кандай параметрлер менен бара жаткандыгы тууралуу маалыматты алат. Istio-policy Саясат эрежелери канааттандырылганын текшерүү үчүн сурамдарды кабыл алат. Политика текшерүүлөрү, албетте, ар бир суроо-талап боюнча жүргүзүлбөйт, бирок белгилүү бир убакытка кардарда кэште сакталат. Отчеттук текшерүүлөр партия сурамдары катары жөнөтүлөт. Кантип конфигурациялоону жана кандай параметрлерди бир аздан кийин жөнөтүү керектигин карап көрөлү.
Миксер телеметриялык маалыматтарды чогултуу жана иштетүү боюнча үзгүлтүксүз ишти камсыз кылуучу жогорку жеткиликтүү компонент болушу керек. Натыйжада система көп деңгээлдүү буфер катары алынат. Башында, маалыматтар контейнерлердин каптал тарабында буферделет, андан кийин аралаштыргыч тарапта, андан кийин аралаштыргычтын арткы четине жөнөтүлөт. Натыйжада, системанын компоненттеринин бири иштебей калса, буфер чоңоюп, система калыбына келтирилгенден кийин тазаланат. Миксердин аркалары телеметрия маалыматтарын жөнөтүү үчүн акыркы чекиттер болуп саналат: statsd, newrelic ж.б. Сиз өзүңүздүн бэкендиңизди жазсаңыз болот, бул абдан жөнөкөй жана биз муну кантип жасоону көрөбүз.
Жыйынтыктап айтканда, истио-телеметрия менен иштөө схемасы төмөнкүдөй.
- 1-кызмат 2-кызматка суроо-талап жөнөтөт.
- 1-кызматтан чыгууда суроо-талап өзүнүн капталына оролот.
- Sidecar өкүлү суроо-талаптын 2-кызматка кантип барарын көзөмөлдөп, керектүү маалыматты даярдайт.
- Андан кийин Отчет сурамынын жардамы менен аны истио-телеметрияга жөнөтөт.
- Истио-телеметрия бул Отчеттун серверге жөнөтүлүшү керекпи же жокпу, кайсынысына жана кандай маалыматтар жөнөтүлүшү керектигин аныктайт.
- Istio-temeterry керек болсо, отчеттун маалыматтарын серверге жөнөтөт.
Эми негизги компоненттерден (Пилот жана капталдагы өкүл) гана турган системада 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
Бардык негизги башкаруу компоненттери (башкаруу тегиздиги) 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 жана Кызмат CIDR бардык кластерлерде уникалдуу болушу керек жана бири-бирине дал келбеши керек.
- Бардык CIDR Поддор кластерлердин ортосундагы бардык CIDR Podдордон жеткиликтүү болушу керек.
- Бардык Kubernetes API серверлери бири-бирине жеткиликтүү болушу керек.
Бул Istio менен баштоого жардам бере турган алгачкы маалымат. Бирок, дагы эле көп мүчүлүштүктөр бар. Мисалы, тышкы трафикти (кластерден тышкары) багыттоо өзгөчөлүктөрү, капталдагы мүчүлүштүктөрдү оңдоо ыкмалары, профилдөө, миксерди орнотуу жана ыңгайлаштырылган аралаштыргыч бэкэндди жазуу, көзөмөлдөө механизмин орнотуу жана элчи аркылуу анын иштеши.
Мунун баарын биз кийинки басылмаларда карап чыгабыз. Суроолоруңузду бериңиз, мен аларды чагылдырууга аракет кылам.
Source: www.habr.com