Интернетте (кызмат сетка), бул жерде дагы бир. Жашасын! Бирок эмне үчүн? Андан кийин, мен Docker жана Kubernetes сыяктуу контейнер платформалары пайда болгонго чейин, тейлөө торлору 10 жыл мурун жакшыраак болмок деген оюмду айткым келет. Мен өзүмдүн көз карашымды башкаларга караганда жакшыраак же жаман деп айтуудан алысмын, бирок тейлөө торлору абдан татаал жаныбарлар болгондуктан, бир нече көз караштар аларды жакшыраак түшүнүүгө жардам берет.
Мен жүздөн ашык микросервистерге курулган жана контейнерлердеги миңдеген тиркемелерди колдогон dotCloud платформасы жөнүндө сүйлөшөм. Мен аны иштеп чыгууда жана ишке киргизүүдө кандай кыйынчылыктарга туш болгонубузду жана кызмат торлору кантип жардам берерин (же жардам бербеши мүмкүн) түшүндүрүп берем.
dotcloud тарыхы
Мен буга чейин dotCloud тарыхы жана бул платформа үчүн архитектураны тандоо жөнүндө жазганмын, бирок тармак катмары жөнүндө көп айткан жокмун. Эгер окугуңуз келбесе dotCloud жөнүндө, анын өзөгү: бул PaaS платформасы-кызмат, ал кардарларга кеңири диапазондогу колдонмолорду (Java, PHP, Python...) иштетүүгө мүмкүндүк берет, маалымат кызматтарынын кеңири спектрин колдоого алат ( MongoDB, MySQL, Redis...) жана Heroku сыяктуу иш процесси: сиз өз кодуңузду платформага жүктөйсүз, ал контейнер сүрөттөрүн түзүп, аларды жайгаштырат.
Мен сизге трафик кантип dotCloud платформасына жөнөтүлгөнүн айтып берем. Бул өзгөчө сонун болгон үчүн эмес (система өз убагында жакшы иштеген!), бирок, биринчи кезекте, заманбап инструменттердин жардамы менен, мындай дизайнды жөнөкөй команда кыска убакыттын ичинде оңой эле ишке ашыра алат, эгерде аларга маршрутка жол керек болсо. микросервистердин же бир топ тиркемелердин ортосундагы трафик. Ошентип, сиз варианттарды салыштыра аласыз: эгерде сиз бардыгын өзүңүз иштеп чыксаңыз же учурдагы тейлөө тармагын колдонсоңуз, эмне болот. Стандарттык тандоо: өзүңүз жасаңыз же сатып алыңыз.
Хостталган тиркемелер үчүн трафикти багыттоо
DotCloud'тагы тиркемелер HTTP жана TCP акыркы чекиттерин ачыкка чыгарышы мүмкүн.
HTTP акыркы чекиттери жүк баланстоочу кластер конфигурациясына динамикалык түрдө кошулган . Бул ресурстар бүгүнкү күндө эмне кылып жатканына окшош Kubernetes жана жүк баланстоочу сыяктуу .
Кардарлар тиешелүү домендер аркылуу HTTP акыркы чекиттерине туташат, домен аталышы dotCloud жүк балансчыларына упайларды берет. Өзгөчө эч нерсе жок.
TCP акыркы чекиттери порт номери менен байланышкан, ал андан кийин чөйрө өзгөрмөлөрү аркылуу ошол стектеги бардык контейнерлерге өткөрүлөт.
Кардарлар TCP акыркы чекиттерине тиешелүү хост атын (gateway-X.dotcloud.com сыяктуу) жана порт номерин колдонуп туташа алышат.
Бул хост аты "nats" сервер кластерине чечилет ( ) кирүүчү TCP туташууларын туура контейнерге (же жүк балансталган кызматтарда туура контейнерлерге) багыттайт.
Эгер сиз Kubernetes менен тааныш болсоңуз, анда бул сизге кызматтарды эскертет .
dotCloud платформасында эквиваленттүү кызматтар жок болчу : жөнөкөйлүк үчүн, кызматтарга жетүү платформанын ичинен да, сыртынан да бирдей болгон.
Баары жөнөкөй уюштурулган: HTTP жана TCP багыттоо тармактарынын оригиналдуу ишке ашырылышы Pythonдун бир нече жүз гана саптары болгон. Платформанын өсүшү жана кошумча талаптардын пайда болушу менен такталган жөнөкөй (мен айтаар элем) алгоритмдер.
Учурдагы кодду кеңири рефакторинг талап кылынган эмес. Өзгөчө, чөйрө өзгөрмөлөрү аркылуу алынган даректи түздөн-түз колдоно алат.
Бул заманбап тейлөө торунан эмнеси менен айырмаланат?
Чектелген көрүнөө. Бизде TCP багыттоо торунун эч кандай көрсөткүчтөрү болгон эмес. HTTP багыттоосу жөнүндө сөз болгондо, акыркы версияларда ката коддору жана жооп берүү убакыттары бар деталдуу HTTP метрикалары бар, бирок заманбап тейлөө торлору, мисалы, Prometheus сыяктуу метрикаларды чогултуу тутумдары менен интеграцияны камсыз кылуу менен андан да ары барат.
Көрүнүү операциялык көз караштан гана эмес (көйгөйлөрдү чечүүгө жардам берүү үчүн), ошондой эле жаңы функциялар чыгарылганда да маанилүү. коопсуз жөнүндө сөз и .
Маршруттун натыйжалуулугу да чектелген. DotCloud маршруттук торчосунда бардык трафик атайын багыттоо түйүндөрүнүн кластери аркылуу өтүшү керек болчу. Бул бир нече AZ (жеткиликтүүлүк зонасы) чектерин кесип өтүүнү жана күтүү убактысынын олуттуу өсүшүн билдирген. Мен бир бетке жүздөн ашык SQL сурамдарын жасаган жана ар бир суроо үчүн SQL серверине жаңы туташууну ачкан көйгөйлөрдү чечүү коду эсимде. Жергиликтүү иштетилгенде, барак заматта жүктөлөт, бирок dotCloud'та жүктөө бир нече секунд талап кылынат, анткени ар бир TCP туташуусу (жана кийинки SQL сурамы) ондогон миллисекундду талап кылат. Бул учурда, туруктуу байланыштар көйгөйдү чечти.
Заманбап тейлөө торлору мындай көйгөйлөрдү чечүүдө жакшыраак. Биринчиден, алар байланыштар багытталганын текшеришет булакта. Логикалык агым бирдей: клиент → меш → сервис, бирок азыр сетка алыскы түйүндөрүндө эмес, жергиликтүү иштейт, ошондуктан байланыш клиент → меш жергиликтүү жана абдан тез (миллисекунддун ордуна микросекунд).
Заманбап тейлөө торлору дагы акылдуураак жүктү тең салмактоо алгоритмдерин ишке ашырат. Backends ден соолугуна мониторинг жүргүзүү менен, алар жакшыраак жалпы аткарууну алып, тезирээк бэкенддерге көбүрөөк трафик жөнөтө алат.
коопсуздук дагы жакшыраак. DotCloud маршруттук торчосу толугу менен EC2 Classicте иштеген жана трафикти шифрлеген эмес (эгер кимдир бирөө EC2 тармактык трафигине снайфер коюуга үлгүрсө, сиз чоң кыйынчылыкка кабылдыңыз деген божомол менен). Заманбап тейлөө торлору биздин бардык трафикти ачык-айкын коргойт, мисалы, өз ара TLS аутентификациясы жана кийинки шифрлөө менен.
Платформа кызматтары үчүн трафикти багыттоо
Макул, биз тиркемелердин ортосундагы трафикти талкууладык, бирок dotCloud платформасынын өзү жөнүндө эмне айтууга болот?
Платформанын өзү ар кандай функциялар үчүн жооптуу жүзгө жакын микросервистерден турган. Кээ бирлери башкалардын суроо-талаптарын кабыл алып жатышты, ал эми кээ бирлери башка кызматтарга туташып, бирок өзүлөрү байланыштарды кабыл алган эмес. Кандай болбосун, ар бир кызмат туташуу керек болгон даректердин акыркы чекиттерин билиши керек.
Көптөгөн жогорку деңгээлдеги кызматтар жогоруда сүрөттөлгөн маршруттук торду колдонушу мүмкүн. Чынында, XNUMXдөн ашык dotCloud микросервистеринин көбү dotCloud платформасынын өзүндө кадимки тиркемелер катары орнотулган. Бирок аз сандагы төмөнкү деңгээлдеги кызматтарга (атап айтканда, бул маршруттук торду ишке ашыргандар) көз карандылыгы азыраак жөнөкөй нерсе керек болчу (анткени алар иштөө үчүн өздөрүнөн көз каранды эмес - эски тоок жана жумуртка маселеси).
Бул төмөнкү деңгээлдеги, маанилүү кызматтар контейнерлерди түздөн-түз бир нече негизги түйүндөрдө иштетүү аркылуу жайгаштырылды. Ошол эле учурда стандарттык платформа кызматтары тартылган эмес: шилтеме берүүчү, пландоочу жана жөө күлүк. Эгер сиз заманбап контейнер платформалары менен салыштыргыңыз келсе, бул башкаруучу учакты учуруу сыяктуу docker run тапшырманы Kubernetesке тапшыруунун ордуна түздөн-түз түйүндөрдө. Бул концепция боюнча абдан окшош , колдонот же өз алдынча кластерди жүктөөдө.
Бул кызматтар жөнөкөй жана одоно түрдө ачыкка чыкты: YAML файлында алардын аты-жөнү жана дареги көрсөтүлгөн; жана ар бир кардар жайылтуу үчүн бул YAML файлынын көчүрмөсүн алышы керек болчу.
Бир жагынан алганда, бул өтө ишенимдүү, анткени ал Zookeeper сыяктуу тышкы ачкыч/нарк дүкөнүнүн колдоосун талап кылбайт (эсте, etcd же Консул ал убакта жок болчу). Башка жагынан алып караганда, бул кызматтарды жылдырууну кыйындаткан. Кыймыл жасалган сайын, бардык кардарлар жаңыртылган YAML файлын (жана мүмкүн кайра жүктөө) алышы керек болчу. Өтө ыңгайлуу эмес!
Кийинчерээк биз жаңы схеманы ишке киргизе баштадык, анда ар бир кардар локалдык прокси серверге туташкан. Даректин жана порттун ордуна, ал кызматтын порт номерин билип, аркылуу туташуу керек localhost. Жергиликтүү прокси бул байланышты иштетип, аны чыныгы серверге багыттайт. Эми серверди башка машинага жылдырганда же масштабдоодо, бардык кардарларды жаңыртуунун ордуна, ушул бардык жергиликтүү проксилерди гана жаңыртуу керек; жана кайра жүктөө талап кылынбайт.
(Ошондой эле TLS туташууларында трафикти инкапсуляциялоо жана кабыл алуучу тарапка башка прокси серверди орнотуу, ошондой эле туташууну кабыл алуу үчүн конфигурацияланган кабыл алуучу кызматтын катышуусуз TLS сертификаттарын текшерүү пландаштырылган. localhost. Бул тууралуу кийинчерээк).
Бул абдан окшош Airbnb'ден, бирок олуттуу айырмачылык SmartStack ишке ашырылып, өндүрүшкө орнотулат, ал эми dotCloud'тун ички маршруттук системасы dotCloud Dockerге айланганда кутучага салынган.
Мен жеке өзүм SmartStackти Istio, Linkerd жана Consul Connect сыяктуу системалардын мурункуларынын бири деп эсептейм, анткени алардын баары бирдей үлгүнү карманышат:
- Ар бир түйүндө прокси иштетиңиз.
- Кардарлар проксиге туташат.
- Башкаруу тегиздиги прокси конфигурациясын серверлер өзгөргөндө жаңыртат.
- … Пайда!
Заманбап тейлөө тармагын ишке ашыруу
Бүгүнкү күндө ушундай торду ишке ашыруу керек болсо, биз окшош принциптерди колдоно алабыз. Мисалы, кызмат аталыштарын мейкиндиктеги даректерге түшүрүү менен ички DNS аймагын орнотуңуз 127.0.0.0/8. Андан кийин ар бир кластер түйүнүндө HAProxy иштетиңиз, ар бир кызмат дареги боюнча байланыштарды кабыл алыңыз (ошол ички тармакта 127.0.0.0/8) жана жүктү тиешелүү арткы чектерге багыттоо/баландаштыруу. HAProxy конфигурациясын башкарууга болот , сизге backend маалыматты etcd же Консулда сактоого жана керек болгондо жаңыртылган конфигурацияны HAProxyге автоматтык түрдө түртүүгө мүмкүндүк берет.
Истио ушундай иштейт! Бирок кээ бир айырмачылыктар менен:
- колдонот HAProxy ордуна.
- Beckend конфигурациясын etcd же Консулдун ордуна Kubernetes API аркылуу сактайт.
- Кызматтарга даректер 127.0.0.0/8дин ордуна ички ички тармакта (Kubernetes ClusterIP даректери) бөлүнгөн.
- Кардар менен серверлердин ортосунда өз ара TLS аутентификациясын кошуу үчүн кошумча компонент (Citadel) бар.
- Жаңы функцияларды колдойт, мисалы, схемаларды үзүү, бөлүштүрүлгөн издөө, канарларды жайылтуу ж.б.
Келгиле, айрым айырмачылыктарды тез карап көрөлү.
Элчи прокси
Envoy Proxy Lyft тарабынан жазылган [Uberдин такси рыногундагы атаандашы - болжол менен. пер.]. Бул башка проксилерге көп жагынан окшош (мисалы, HAProxy, Nginx, Traefik...), бирок Lyft өздөрү жазган, анткени алар башка проксилерде жок өзгөчөлүктөргө муктаж жана кеңейтүүнүн ордуна жаңысын жасоо акылга сыярлык көрүнгөн. бар.
Элчи өз алдынча колдонсо болот. Эгерде менде башка кызматтарга туташуу керек болгон белгилүү бир кызмат болсо, мен аны Envoy менен туташуу үчүн орното алам, андан кийин башка кызматтардын жайгашкан жери менен Элчисин динамикалык конфигурациялап, кайра конфигурациялай алам, мында көрүнүү сыяктуу көптөгөн сонун кошумчаларды алам. Ыңгайлаштырылган кардар китепканасынын же чалууларды көзөмөлдөө кодуна инъекциянын ордуна, биз Элчиге трафик жөнөтөбүз жана ал биз үчүн көрсөткүчтөрдү чогултат.
Бирок Элчи ошондой эле иштей алат маалымат учак (маалымат учагы) кызматтык тор үчүн. Бул азыр бул кызмат торчосу үчүн Элчи конфигурацияланган дегенди билдирет башкаруу учагы (башкаруу учагы).
Башкаруучу учак
Башкаруу тегиздигинде, Istio Kubernetes API'ге таянат. Бул confd колдонуудан анча деле айырмаланбайт, маалымат сактагычынан ачкычтардын топтомун издөө үчүн etcd же Консулга таянат. Istio Kubernetes API аркылуу Kubernetes ресурстарынын топтомун карап чыгат.
Ушул жана андан кийин: Жеке мен муну пайдалуу деп таптым анда мындай деп айтылат:
Kubernetes API Server - бул сактоо, версиялоо, текшерүү, жаңыртуу жана API ресурстук семантикасын сунуш кылган "акылсыз сервер".
Istio Kubernetes менен иштөө үчүн иштелип чыккан; жана эгер сиз аны Kubernetes'тен тышкары колдонгуңуз келсе, анда сиз Kubernetes API серверинин (жана etcd жардамчы кызматы) бир нускасын башташыңыз керек.
Кызмат даректери
Istio Kubernetes бөлүп берген ClusterIP даректерине таянат, ошондуктан Istio кызматтары ички даректи алат (диапазондо эмес) 127.0.0.0/8).
Istio жок Kubernetes кластериндеги белгилүү бир кызмат үчүн ClusterIP дарегине трафик kube-прокси тарабынан кармалып, проксидин арткы четине жөнөтүлөт. Эгерде сизди техникалык деталдар кызыктырса, kube-proxy ClusterIP дарегине бара турган байланыштардын көздөгөн IP даректерин кайра жазуу үчүн iptables эрежелерин (же IPVS жүк балансын түзүүчүлөрдү) орнотот.
Istio Kubernetes кластерине орнотулгандан кийин, ал контейнерди киргизүү менен берилген керектөөчүгө, ал тургай бүт аттар мейкиндигине ачык иштетилмейинче эч нерсе өзгөрбөйт. sidecar ыңгайлаштырылган кабыктарга. Бул контейнер Envoy инстанциясын баштайт жана башка кызматтарга бара турган трафикти токтотуу жана бул трафикти Элчиге багыттоо үчүн iptables эрежелеринин топтомун орнотот.
Kubernetes DNS менен интеграцияланганда, бул биздин код кызматтын аталышы боюнча туташа алат жана бардыгы "жөн эле иштейт" дегенди билдирет. Башкача айтканда, биздин код сыяктуу суроолорду чыгарат http://api/v1/users/4242ошондо api өтүнүчүн чечүү 10.97.105.48, iptables эрежелери 10.97.105.48ден туташууларды токтотуп, аларды жергиликтүү Элчи проксиге багыттайт, ал өтүнүчтү чыныгы API серверине жөнөтөт. Фу!
Кошумча бурчтар
Istio ошондой эле mTLS (өз ара TLS) аркылуу аягына чейин шифрлөө жана аутентификацияны камсыз кылат. компоненти чакырды Citadel.
компоненти да бар аралаштыргыч, Кайсы Элчи сурай алат ар биринин ар кандай факторлорго жараша ошол өтүнүч боюнча атайын чечим кабыл алуу өтүнүчү, мисалы, аталыштар, арткы жүктөө ж.б.... (кабатыр болбоңуз: Миксердин иштешин камсыз кылуу үчүн көптөгөн куралдар бар жана ал бузулуп калса дагы, Элчи ишин улантат прокси катары).
Жана, албетте, биз көрүнүү жөнүндө айттык: Элчи бөлүштүрүлгөн байкоону камсыз кылуу менен бирге чоң көлөмдөгү метрикаларды чогултат. Микросервистердин архитектурасында, эгерде бир API сурамы A, B, C жана D микросервистери аркылуу өтүшү керек болсо, анда логинге киргенден кийин, бөлүштүрүлгөн трасса суроо-талапка уникалдуу идентификаторду кошот жана бул идентификаторду ушул микросервистердин бардык субсуроолор аркылуу сактайт. сиз бардык байланышкан чалууларды, алардын кечигүүлөрүн ж.б.
Өнүктүрүү же сатып алуу
Istio татаал система катары кадыр-баркка ээ. Ал эми, мен бул посттун башында сүрөттөгөн маршруттук торду куруу учурдагы куралдар менен салыштырмалуу оңой. Демек, анын ордуна өзүңүздүн кызматтык торуңузду түзүү мааниси барбы?
Эгерде бизде жөнөкөй муктаждыктар болсо (бизге көрүнүү, автоматтык өчүргүч жана башка кылдаттык керек эмес), анда ойлор өзүбүздүн куралыбызды иштеп чыгуу жөнүндө келет. Бирок, эгерде биз Kubernetes'ти колдонуп жаткан болсок, анда анын кереги деле жок болушу мүмкүн, анткени Kubernetes мурунтан эле кызматты ачуу жана жүктү тең салмактоо үчүн негизги куралдарды камсыз кылат.
Бирок бизде өркүндөтүлгөн талаптар болсо, анда сервистик торду "сатып алуу" алда канча жакшыраак вариант сыяктуу көрүнөт. (Istio ачык булак болгондуктан, бул дайыма эле "сатып алуу" эмес, бирок биз аны түшүнүү, жайылтуу жана башкаруу үчүн дагы эле инженердик убакытты жумшашыбыз керек.)
Эмне тандоо керек: Istio, Linkerd же Consul Connect?
Азырынча биз Istio жөнүндө гана сөз кылдык, бирок бул жалгыз кызматтык тор эмес. Популярдуу альтернатива болуп саналат , бирок дагы бар .
тандап Эмне көрүүгү болот?
Чынын айтсам билбейм. Учурда мен бул суроого жооп берүүгө өзүмдү компетенттүү деп эсептебейм. Бир нече бар бул куралдарды салыштыруу менен жана ал тургай .
Бир келечектүү ыкма сыяктуу куралды колдонуу болуп саналат . Бул кызмат торлору тарабынан берилген API'лерди жөнөкөйлөтүү жана унификациялоо үчүн абстракция катмарын ишке ашырат. Ар кандай сервистик торлордун конкреттүү (жана, менин оюмча, салыштырмалуу татаал) API'лерин үйрөнүүнүн ордуна, биз жөнөкөй SuperGloo конструкцияларын колдонсок болот - жана бизде HTTP интерфейстерин жана бэкенддерин сүрөттөгөн ортодогу конфигурация форматы болгон сыяктуу биринен экинчисине оңой которула алабыз. Nginx, HAProxy, Traefik, Apache үчүн чыныгы конфигурацияны түзүүгө жөндөмдүү…
Мен Istio жана SuperGloo менен бир аз ойнодум, жана кийинки макалада Istio же Linkerdди SuperGloo аркылуу учурдагы кластерге кантип кошууга болорун жана акыркысы өз ишин кантип аткарарын, башкача айтканда, ал сизге которууга мүмкүндүк берет. конфигурацияларды кайра жазбастан бир кызматтык торду экинчисине өткөрүү.
Source: www.habr.com