Кутмандуу күн, мен сиз менен Windows контейнерлери үчүн AWS EKS (Elastic Kubernetes Service) кызматын орнотуу жана колдонуу боюнча тажрыйбам менен бөлүшкүм келет, тагыраак айтканда, аны колдонуунун мүмкүн эместиги жана AWS тутумунун контейнеринде табылган мүчүлүштүктөр үчүн. Windows контейнерлери үчүн бул кызматка кызыккандар, кошка астында сураныч.
Мен Windows контейнерлери популярдуу тема эмес экенин билем жана аларды аз адамдар колдонушат, бирок мен дагы эле бул макаланы жазууну чечтим, анткени Habré жөнүндө kubernetes жана Windows боюнча бир нече макалалар болгон жана дагы деле ушундай адамдар бар.
баштап
Мунун баары биздин компаниядагы кызматтарды 70% Windows жана 30% Linux болгон kubernetesке көчүрүү чечими кабыл алынганда башталды. Бул максатта AWS EKS булут кызматы мүмкүн болгон варианттардын бири катары каралган. 8-жылдын 2019-октябрына чейин AWS EKS Windows Коомдук алдын ала кароо режиминде болчу, мен аны менен баштадым, ал жерде кубернеттердин эски 1.11 версиясы колдонулган, бирок мен баары бир аны текшерип, бул булут кызматы кайсы этапта экенин, ал иштеп жатканын көрүүнү чечтим. дегеле, белгилүү болгондой, жок, бул жерде капчыктарды алып салуу менен ката бар болчу, ал эми эскилери Windows жумушчу түйүнү менен бир эле ички тармактан ички IP аркылуу жооп бербей калышты.
Ошондуктан, ошол эле EC2деги кубернеттерде өзүбүздүн кластердин пайдасына AWS EKS колдонуудан баш тартуу чечими кабыл алынды, болгону биз бардык тең салмактуулукту жана HAны CloudFormation аркылуу өзүбүз сүрөттөшүбүз керек.
Amazon EKS Windows Container Support азыр Жалпысынан жеткиликтүү
Мартин Биби | 08-жылдын 2019-октябрында
Мен өзүмдүн кластерим үчүн CloudFormationге шаблон кошууга үлгүрбөй эле, мен бул жаңылыкты көрдүм.
Албетте, мен бардык жумушумду четке кагып, алар GA үчүн эмне кылганын жана Public Preview менен баары кандай өзгөргөнүн изилдей баштадым. Ооба, AWS, жакшы, Windows жумушчу түйүнү үчүн сүрөттөрдү 1.14 версиясына жаңыртты, ошондой эле кластердин өзү, EKSдеги 1.14 версиясы азыр Windows түйүндөрүн колдойт. Коомдук алдын ала көрүү боюнча долбоор Алар муну жаап-жашырышып, азыр бул жерде расмий документтерди колдонгула дешти:
EKS кластерин учурдагы VPCге жана субсеттерге интеграциялоо
Бардык булактарда, кулактандыруудагы жогорудагы шилтемеде, ошондой эле документтерде, кластерди жеке эксctl утилитасы аркылуу же CloudFormation + kubectl аркылуу жайылтуу сунушталган, андан кийин Амазондогу коомдук субсеталарды колдонуу, ошондой эле жаңы кластер үчүн өзүнчө VPC.
Бул параметр көптөр үчүн ылайыктуу эмес, биринчиден, өзүнчө VPC анын баасы + учурдагы VPC трафик үчүн кошумча чыгымдарды билдирет; AWSде даяр инфраструктурага ээ болгондор өздөрүнүн бир нече AWS каттоо эсептери, VPC, субторлор, маршруттук таблицалар, транзиттик шлюз жана башкалар менен эмне кылышы керек? Албетте, сиз мунун баарын бузуп же кайра жасагыңыз келбейт жана сиз жаңы EKS кластерин учурдагы тармактык инфраструктурага, учурдагы VPCди колдонуу менен интеграциялашыңыз керек жана бөлүү үчүн көбүнчө кластер үчүн жаңы ички тармактарды түзүшүңүз керек.
Менин учурда, бул жол тандалды, мен учурдагы VPCди колдондум, жаңы кластер үчүн болгону 2 коомдук субсеттерди жана 2 жеке ички тармактарды коштум, албетте, бардык эрежелер документтерге ылайык эске алынган .
Ошондой эле бир шарт бар болчу: EIPди колдонгон коомдук субсеттерде жумушчу түйүндөр жок.
eksctl vs CloudFormation
Мен дароо эскертип коём, мен кластерди жайгаштыруунун эки ыкмасын тең сынап көрдүм, эки учурда тең сүрөт бирдей болду.
Мен мисалды eksctl менен гана көрсөтөм, анткени бул жерде код кыскараак болот. eksctl колдонуп, кластерди 3 кадам менен жайгаштырыңыз:
1. Биз кластердин өзүн + Linux жумушчу түйүнүн түзөбүз, ал кийинчерээк система контейнерлерин жана ошол эле начар vpc-контроллерин жайгаштырат.
eksctl create cluster
--name yyy
--region www
--version 1.14
--vpc-private-subnets=subnet-xxxxx,subnet-xxxxx
--vpc-public-subnets=subnet-xxxxx,subnet-xxxxx
--asg-access
--nodegroup-name linux-workers
--node-type t3.small
--node-volume-size 20
--ssh-public-key wwwwwwww
--nodes 1
--nodes-min 1
--nodes-max 2
--node-ami auto
--node-private-networkingУчурдагы VPCге жайгаштыруу үчүн, жөн гана субторлоруңуздун идентификаторун көрсөтүңүз, жана eksctl VPCдин өзүн аныктайт.
Жумушчу түйүндөрүңүздүн жеке ички тармакка гана жайгаштырылышын камсыз кылуу үчүн, сиз түйүн тобу үчүн --node-private-networking белгилешиңиз керек.
2. Биз кластерибизге vpc-контроллерин орнотобуз, ал андан кийин жумушчу түйүндөрүбүздү иштетип, бекер IP даректердин санын, ошондой эле инстанциядагы ENI санын эсептеп, аларды кошуп жана алып салат.
eksctl utils install-vpc-controllers --name yyy --approve3.Системанын контейнерлери Linux жумушчу түйүнүңүздө ийгиликтүү ишке киргенден кийин, анын ичинде vpc-контроллер, Windows жумушчулары менен башка түйүн тобун түзүү гана калды.
eksctl create nodegroup
--region www
--cluster yyy
--version 1.14
--name windows-workers
--node-type t3.small
--ssh-public-key wwwwwwwwww
--nodes 1
--nodes-min 1
--nodes-max 2
--node-ami-family WindowsServer2019CoreContainer
--node-ami ami-0573336fc96252d05
--node-private-networkingТүйүн кластериңизге ийгиликтүү туташкандан кийин жана баары жакшы болуп көрүнгөндөн кийин, ал Даяр статусунда, бирок жок.
vpc контроллерундагы ката
Эгерде биз терезелердин жумушчу түйүнүндө подкасттарды иштетүүгө аракет кылсак, катаны алабыз:
NetworkPlugin cni failed to teardown pod "windows-server-iis-7dcfc7c79b-4z4v7_default" network: failed to parse Kubernetes args: pod does not have label vpc.amazonaws.com/PrivateIPv4Address]Эгер тереңирээк карай турган болсок, AWSдеги мисалыбыз төмөнкүдөй экенин көрөбүз:
Жана мындай болушу керек:
Ушундан көрүнүп тургандай, vpc-контроллери кандайдыр бир себептерден улам өз бөлүгүн аткарбай калган жана инстанцияга жаңы IP даректерди кошо албагандыктан, аларды подряддар колдоно албайт.
Келгиле, vpc-контроллер подкастынын журналдарын карап көрөлү жана биз көргөн нерсе:
kubectl журналы -n kube-системасы
I1011 06:32:03.910140 1 watcher.go:178] Node watcher processing node ip-10-xxx.ap-xxx.compute.internal.
I1011 06:32:03.910162 1 manager.go:109] Node manager adding node ip-10-xxx.ap-xxx.compute.internal with instanceID i-088xxxxx.
I1011 06:32:03.915238 1 watcher.go:238] Node watcher processing update on node ip-10-xxx.ap-xxx.compute.internal.
E1011 06:32:08.200423 1 manager.go:126] Node manager failed to get resource vpc.amazonaws.com/CIDRBlock pool on node ip-10-xxx.ap-xxx.compute.internal: failed to find the route table for subnet subnet-0xxxx
E1011 06:32:08.201211 1 watcher.go:183] Node watcher failed to add node ip-10-xxx.ap-xxx.compute.internal: failed to find the route table for subnet subnet-0xxx
I1011 06:32:08.201229 1 watcher.go:259] Node watcher adding key ip-10-xxx.ap-xxx.compute.internal (0): failed to find the route table for subnet subnet-0xxxx
I1011 06:32:08.201302 1 manager.go:173] Node manager updating node ip-10-xxx.ap-xxx.compute.internal.
E1011 06:32:08.201313 1 watcher.go:242] Node watcher failed to update node ip-10-xxx.ap-xxx.compute.internal: node manager: failed to find node ip-10-xxx.ap-xxx.compute.internal.Google'дагы издөөлөр эч нерсеге алып келген жок, анткени мындай мүчүлүштүктөрдү азырынча эч ким кармай элек, же ага маселе жарыялай элек болчу, мен адегенде варианттарды өзүм ойлонушум керек болчу. Биринчи ойго келген нерсе, балким, vpc-контроллери ip-10-xxx.ap-xxx.compute.internal чече албайт жана ага жете албайт, ошондуктан каталар пайда болот.
Ооба, чынында эле, биз VPCде ыңгайлаштырылган DNS серверлерин колдонобуз жана, негизинен, биз Amazon серверлерин колдонбойбуз, андыктан бул ap-xxx.compute.internal домен үчүн багыттоо да конфигурацияланган эмес. Мен бул вариантты сынап көрдүм, бирок натыйжа берген жок, балким, тест таза эмес болчу, ошондуктан, андан ары техникалык колдоо менен байланышып жатканда, мен алардын идеясына багындым.
Чынында эле эч кандай идеялар болбогондуктан, бардык коопсуздук топтору eksctl өзү тарабынан түзүлгөн, ошондуктан алардын кызматка жарамдуулугуна эч кандай шек жок, маршруттук таблицалар да туура, nat, dns, жумушчу түйүндөр менен Интернетке кирүү да бар болчу.
Мындан тышкары, эгерде сиз жумушчу түйүндү — node-private-networking колдонбостон коомдук ички тармакка жайгаштырсаңыз, бул түйүн vpc контроллери тарабынан дароо жаңыртылган жана бардыгы сааттын механизминдей иштеген.
Эки вариант бар эле:
- Андан баш тартыңыз жана кимдир бирөө AWSде бул мүчүлүштүктөрдү сүрөттөп бергенге чейин күтө туруңуз жана алар аны оңдошот, ошондо сиз AWS EKS Windowsту коопсуз колдонсоңуз болот, анткени алар GA-да жаңы эле чыгарылган (бул макаланы жазып жаткан учурда 8 күн өттү), балким, көпчүлүк мен сыяктуу жол менен жүр.
- AWS Колдоо кызматына жазыңыз жана аларга бардык жерден келген журналдардын бүтүндөй тобу менен маселенин маңызын айтып бериңиз жана аларга сиздин VPC жана субсеталарды колдонууда алардын кызматы иштебей турганын далилдеңиз, бизде Бизнести колдоо бекер эмес, сиз колдонушуңуз керек. жок дегенде бир жолу :)
AWS инженерлери менен байланыш
Порталда билет түзүп, мен жаңылыш түрдө мага Веб - электрондук почта же колдоо борбору аркылуу жооп берүүнү туура көрдүм, бул опция аркылуу алар сизге бир нече күндөн кийин жооп бере алышат, менин билетимдин катаалдыгы - система бузулганына карабастан. <12 сааттын ичинде жооп кайтарууну билдирген жана Бизнести колдоо планы 24/7 колдоосуна ээ болгондуктан, мен эң жакшы деп үмүттөндүм, бирок ал ар дайымкыдай болду.
Менин билетим жумадан дүйшөмбүгө чейин дайынсыз калды, андан кийин мен аларга кайра жазууну чечтим жана Чат жооп опциясын тандадым. Кыска убакыт күткөндөн кийин, Харшад Мадхав мени көрүүгө дайындалды, анан ал башталды...
Биз аны менен 3 саат катары менен онлайн режиминде мүчүлүштүктөрдү оңдодук, журналдарды өткөрүп бердик, көйгөйдү туураш үчүн AWS лабораториясында ошол эле кластерди жайгаштырдык, кластерди мен тараптан кайра түздүк жана башкалар, биз бир гана нерсеге келдик журналдарда мен жогоруда жазган AWS ички домендик аталыштары иштебей жатканы айкын болду жана Харшад Мадхав менден багыттоо түзүүнү суранды, биз ыңгайлаштырылган DNS колдонобуз жана бул көйгөй болушу мүмкүн.
багытталууда
ap-xxx.compute.internal -> 10.x.x.2 (VPC CIDRBlock)
amazonaws.com -> 10.x.x.2 (VPC CIDRBlock)Бул эмне болду, Харшад Мадхав аны текшерүү үчүн жооп жазды, бирок жок, резолюция эч кандай жардам берген жок.
Андан кийин дагы 2 инженер менен баарлашуу болду, бири чаттан чыгып кетти, кыязы, ал татаал иштен коркту, экинчиси күнүмдү кайра оңдоонун, журналдарды жөнөтүүнүн, эки тараптан кластерлерди түзүүнүн толук циклине өткөрдү. аягында ал жөн эле жакшы айтты, бул мен үчүн иштейт, мен бул жерде мен расмий документацияда бардыгын этап-этабы менен жасайм жана сиз жана сиз ийгиликке жетесиз.
Мен сыпайылык менен андан чыгып кетүүнү жана көйгөйдү кайдан издешти билбесеңиз, билетиме башка бирөөнү дайындоосун сурандым.
жетер
Үчүнчү күнү мага жаңы инженер Арун Б. дайындалды жана аны менен баарлаша баштаганда эле бул мурунку 3 инженер эмес экени дароо айкын болду. Ал бүт тарыхты окуп чыгып, дароо өзүнүн github'унда болгон ps1деги өз скриптинин жардамы менен журналдарды чогултууну суранды. Андан кийин дагы кластерлерди түзүү, команданын натыйжаларын чыгаруу, журналдарды чогултуу сыяктуу бардык итерациялар менен коштолду, бирок Арун Б. мага берилген суроолорго карап туура багытта бара жатты.
Биз алардын vpc-контроллерлеринде -stderrthreshold=debug функциясын иштетүүгө качан жеттик жана андан кийин эмне болду? Албетте, ал иштебейт) подряд бул параметр менен башталбайт, болгону -stderrthreshold=info иштейт.
Биз бул жерден бүттүк жана Арун Б. ошол эле катаны алуу үчүн менин кадамдарымды кайталоого аракет кылаарын айтты. Эртеси мен Арун Бдан жооп алдым, ал бул ишти таштабай, алардын vpc-контролёрунун кароо кодун алып, анын кайсы жерде жана эмне үчүн иштебей жатканын тапты:
Ошентип, эгерде сиз VPC'иңизде негизги маршрут таблицасын колдонсоңуз, анда демейки боюнча анын vpc-контроллери үчүн өтө зарыл болгон керектүү субторлор менен ассоциациялары жок, коомдук субсеттерде, анын ыңгайлаштырылган маршруттук таблицасы бар. анын ассоциациясы бар.
Негизги маршруттук таблицага керектүү субторлор менен ассоциацияларды кол менен кошуу жана түйүн тобун кайра түзүү менен, бардыгы эң сонун иштейт.
Arun B. чындап эле бул мүчүлүштүктөрдү EKS иштеп чыгуучуларына кабарлайт деп үмүттөнөм жана биз vpc-контроллердин жаңы версиясын көрөбүз, анда баары кутудан чыгып кетет. Учурда эң акыркы версия: 602401143452.dkr.ecr.ap-souteast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
бул көйгөй бар.
Аягына чейин окугандардын баарына рахмат, ишке ашыруудан мурун өндүрүштө колдоно турган нерселердин бардыгын сынап көрүңүз.
Source: www.habr.com