Selamat tengah hari, saya ingin berkongsi dengan anda pengalaman saya dalam menyediakan dan menggunakan perkhidmatan AWS EKS (Perkhidmatan Kubernetes Elastik) untuk bekas Windows, atau lebih tepatnya tentang kemustahilan untuk menggunakannya, dan pepijat yang terdapat dalam bekas sistem AWS, untuk mereka yang berminat dengan perkhidmatan ini untuk bekas Windows, sila di bawah cat.
Saya tahu bahawa bekas Windows bukanlah topik yang popular, dan beberapa orang menggunakannya, tetapi saya masih memutuskan untuk menulis artikel ini, kerana terdapat beberapa artikel tentang HabrΓ© di kubernetes dan Windows dan masih ada orang sedemikian.
bermula
Semuanya bermula apabila diputuskan untuk memindahkan perkhidmatan dalam syarikat kami kepada kubernetes, iaitu 70% Windows dan 30% Linux. Untuk tujuan ini, perkhidmatan awan AWS EKS dianggap sebagai salah satu pilihan yang mungkin. Sehingga 8 Oktober 2019, AWS EKS Windows berada dalam Pratonton Awam, saya mulakan dengannya, versi 1.11 lama kubernetes telah digunakan di sana, tetapi saya memutuskan untuk menyemaknya juga dan melihat di peringkat mana perkhidmatan awan ini, sama ada ia berfungsi sama sekali, ternyata, tidak, terdapat pepijat dengan penambahan mengeluarkan pod, manakala yang lama berhenti bertindak balas melalui ip dalaman dari subnet yang sama dengan nod pekerja tingkap.
Oleh itu, telah diputuskan untuk meninggalkan penggunaan AWS EKS memihak kepada kluster kami sendiri pada kubernetes pada EC2 yang sama, hanya kami yang perlu menerangkan semua pengimbangan dan HA sendiri melalui CloudFormation.
Sokongan Kontena Amazon EKS Windows kini Tersedia Secara Umum
oleh Martin Beeby | pada 08 OKT 2019
Sebelum saya sempat menambah templat pada CloudFormation untuk kluster saya sendiri, saya melihat berita ini
Sudah tentu, saya mengetepikan semua kerja saya dan mula mengkaji perkara yang mereka lakukan untuk GA, dan bagaimana semuanya berubah dengan Pratonton Awam. Ya, AWS, syabas, mengemas kini imej untuk nod pekerja windows kepada versi 1.14, serta kluster itu sendiri, versi 1.14 dalam EKS, kini menyokong nod tingkap. Projek oleh Pratonton Awam di Mereka menutupnya dan berkata kini menggunakan dokumentasi rasmi di sini:
Mengintegrasikan kelompok EKS ke dalam VPC dan subnet semasa
Dalam semua sumber, dalam pautan di atas pada pengumuman dan juga dalam dokumentasi, adalah dicadangkan untuk menggunakan kluster sama ada melalui utiliti eksctl proprietari atau melalui CloudFormation + kubectl selepas, hanya menggunakan subnet awam di Amazon, serta mencipta VPC berasingan untuk kluster baharu.
Pilihan ini tidak sesuai untuk kebanyakan orang; pertama, VPC yang berasingan bermaksud kos tambahan untuk kos + trafik peering ke VPC semasa anda. Apakah yang perlu dilakukan oleh mereka yang sudah mempunyai infrastruktur siap pakai dalam AWS dengan akaun Berbilang AWS, VPC, subnet, jadual laluan, gerbang transit dan sebagainya mereka sendiri? Sudah tentu, anda tidak mahu memecahkan atau membuat semula semua ini, dan anda perlu menyepadukan kluster EKS baharu ke dalam infrastruktur rangkaian semasa, menggunakan VPC sedia ada dan, untuk pengasingan, paling banyak membuat subnet baharu untuk kluster.
Dalam kes saya, laluan ini dipilih, saya menggunakan VPC sedia ada, menambah hanya 2 subnet awam dan 2 subnet peribadi untuk kluster baharu, sudah tentu, semua peraturan telah diambil kira mengikut dokumentasi. .
Terdapat juga satu syarat: tiada nod pekerja dalam subnet awam menggunakan EIP.
eksctl vs CloudFormation
Saya akan membuat tempahan serta-merta bahawa saya telah mencuba kedua-dua kaedah untuk menggunakan kluster, dalam kedua-dua kes gambar adalah sama.
Saya akan menunjukkan contoh hanya menggunakan eksctl kerana kod di sini akan menjadi lebih pendek. Menggunakan eksctl, gunakan kluster dalam 3 langkah:
1. Kami mencipta kluster itu sendiri + nod pekerja Linux, yang kemudiannya akan menjadi tuan rumah bekas sistem dan pengawal vpc malang yang sama.
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-networkingUntuk menggunakan VPC sedia ada, hanya nyatakan id subnet anda dan eksctl akan menentukan VPC itu sendiri.
Untuk memastikan bahawa nod pekerja anda digunakan hanya pada subnet peribadi, anda perlu menentukan --node-private-networking untuk kumpulan node.
2. Kami memasang vpc-controller dalam kelompok kami, yang kemudiannya akan memproses nod pekerja kami, mengira bilangan alamat IP percuma, serta bilangan ENI pada contoh, menambah dan mengalih keluarnya.
eksctl utils install-vpc-controllers --name yyy --approve3. Selepas bekas sistem anda berjaya dilancarkan pada nod pekerja Linux anda, termasuk vpc-controller, yang tinggal hanyalah mencipta kumpulan nod lain dengan pekerja tingkap.
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-networkingSelepas nod anda berjaya disambungkan ke kluster anda dan semuanya kelihatan baik-baik saja, ia berada dalam status Sedia, tetapi tidak.
Ralat dalam vpc-controller
Jika kami cuba menjalankan pod pada nod pekerja windows, kami akan mendapat ralat:
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]Jika kita melihat lebih dalam, kita melihat bahawa contoh kita dalam AWS kelihatan seperti ini:
Dan ia sepatutnya seperti ini:
Daripada ini adalah jelas bahawa pengawal vpc tidak memenuhi bahagiannya atas sebab tertentu dan tidak boleh menambah alamat IP baharu pada contoh supaya pod boleh menggunakannya.
Mari kita lihat log pod pengawal vpc dan inilah yang kita lihat:
log kubectl -n kube-sistem
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.Carian di Google tidak membawa kepada apa-apa, kerana nampaknya belum ada sesiapa yang menangkap pepijat sedemikian, atau belum menyiarkan isu mengenainya, saya terpaksa memikirkan pilihan sendiri terlebih dahulu. Perkara pertama yang terlintas di fikiran ialah mungkin pengawal vpc tidak dapat menyelesaikan ip-10-xxx.ap-xxx.compute.internal dan mencapainya dan oleh itu ralat berlaku.
Ya, sememangnya, kami menggunakan pelayan DNS tersuai dalam VPC dan, pada dasarnya, kami tidak menggunakan yang Amazon, jadi malah pemajuan tidak dikonfigurasikan untuk domain ap-xxx.compute.internal ini. Saya menguji pilihan ini, dan ia tidak membawa hasil, mungkin ujian itu tidak bersih, dan oleh itu, selanjutnya, apabila berkomunikasi dengan sokongan teknikal, saya tunduk kepada idea mereka.
Oleh kerana tidak ada sebarang idea, semua kumpulan keselamatan dicipta oleh eksctl sendiri, jadi tidak ada keraguan tentang kebolehkhidmatan mereka, jadual laluan juga betul, nat, dns, akses Internet dengan nod pekerja juga ada.
Selain itu, jika anda menggunakan nod pekerja ke subnet awam tanpa menggunakan βnode-private-networking, nod ini serta-merta dikemas kini oleh vpc-controller dan semuanya berfungsi seperti kerja jam.
Terdapat dua pilihan:
- Berhenti dan tunggu sehingga seseorang menerangkan pepijat ini dalam AWS dan mereka membetulkannya, dan kemudian anda boleh menggunakan AWS EKS Windows dengan selamat, kerana mereka baru dikeluarkan dalam GA (8 hari telah berlalu pada masa menulis artikel ini), ramai yang mungkin akan ikut jalan yang sama dengan saya.
- Tulis kepada Sokongan AWS dan beritahu mereka intipati masalah dengan sejumlah besar log dari mana-mana dan buktikan kepada mereka bahawa perkhidmatan mereka tidak berfungsi apabila menggunakan VPC dan subnet anda, bukan sia-sia kami mendapat sokongan Perniagaan, anda harus gunakan sekurang-kurangnya sekali :)
Komunikasi dengan jurutera AWS
Setelah membuat tiket di portal, saya tersilap memilih untuk membalas saya melalui Web - e-mel atau pusat sokongan, melalui pilihan ini mereka boleh menjawab anda selepas beberapa hari sama sekali, walaupun tiket saya mengalami Keterukan - Sistem terjejas, yang bermakna respons dalam masa <12 jam, dan memandangkan pelan sokongan Perniagaan mempunyai sokongan 24/7, saya mengharapkan yang terbaik, tetapi ternyata seperti biasa.
Tiket saya ditinggalkan tanpa ditetapkan dari hari Jumaat hingga Isnin, kemudian saya memutuskan untuk menulis kepada mereka sekali lagi dan memilih pilihan respons Sembang. Selepas menunggu sebentar, Harshad Madhav dilantik untuk berjumpa saya, dan kemudian ia bermula...
Kami menyahpepijat dengannya dalam talian selama 3 jam berturut-turut, memindahkan log, menggunakan kluster yang sama dalam makmal AWS untuk meniru masalah, mencipta semula kluster di pihak saya, dan seterusnya, satu-satunya perkara yang kami datangi ialah daripada log adalah jelas bahawa resol tidak berfungsi nama domain dalaman AWS, yang saya tulis di atas, dan Harshad Madhav meminta saya untuk membuat pemajuan, kononnya kami menggunakan DNS tersuai dan ini mungkin menjadi masalah.
Penghantaran
ap-xxx.compute.internal -> 10.x.x.2 (VPC CIDRBlock)
amazonaws.com -> 10.x.x.2 (VPC CIDRBlock)Itulah yang telah dilakukan, hari itu telah berakhir. Harshad Madhav menulis semula untuk menyemaknya dan ia sepatutnya berfungsi, tetapi tidak, resolusi itu tidak membantu sama sekali.
Kemudian terdapat komunikasi dengan 2 lagi jurutera, seorang hanya keluar dari sembang, nampaknya dia takut kes yang kompleks, yang kedua menghabiskan hari saya sekali lagi pada kitaran penuh penyahpepijatan, menghantar log, mencipta kelompok di kedua-dua belah pihak, dalam akhir dia hanya berkata baik, ia berfungsi untuk saya, di sini saya saya melakukan segala-galanya langkah demi langkah dalam dokumentasi rasmi dan anda dan anda akan berjaya.
Yang mana saya dengan sopan memintanya untuk pergi dan menugaskan orang lain untuk tiket saya jika anda tidak tahu di mana untuk mencari masalah itu.
Akhir
Pada hari ketiga, seorang jurutera baru Arun B. telah ditugaskan kepada saya, dan sejak awal komunikasi dengannya, jelas bahawa ini bukan 3 jurutera sebelumnya. Dia membaca keseluruhan sejarah dan segera meminta untuk mengumpul log menggunakan skripnya sendiri pada ps1, yang terdapat pada githubnya. Ini diikuti sekali lagi oleh semua lelaran mencipta kluster, mengeluarkan keputusan arahan, mengumpul log, tetapi Arun B. bergerak ke arah yang betul berdasarkan soalan yang diajukan kepada saya.
Bilakah kami sampai ke tahap mendayakan -stderrthreshold=debug dalam pengawal vpc mereka, dan apa yang berlaku seterusnya? sudah tentu ia tidak berfungsi) pod hanya tidak bermula dengan pilihan ini, hanya -stderrthreshold=info berfungsi.
Kami selesai di sini dan Arun B. berkata bahawa dia akan cuba menghasilkan semula langkah saya untuk mendapatkan ralat yang sama. Keesokan harinya saya menerima maklum balas daripada Arun B. dia tidak meninggalkan kes ini, tetapi mengambil kod semakan pengawal vpc mereka dan menemui tempat di mana ia berada dan mengapa ia tidak berfungsi:
Oleh itu, jika anda menggunakan jadual laluan utama dalam VPC anda, maka secara lalai ia tidak mempunyai kaitan dengan subnet yang diperlukan, yang sangat diperlukan untuk pengawal vpc, dalam kes subnet awam, ia mempunyai jadual laluan tersuai yang mempunyai persatuan.
Dengan menambah perkaitan secara manual untuk jadual laluan utama dengan subnet yang diperlukan, dan mencipta semula kumpulan node, semuanya berfungsi dengan sempurna.
Saya berharap Arun B. benar-benar akan melaporkan pepijat ini kepada pembangun EKS dan kita akan melihat versi baharu pengawal vpc di mana semuanya akan berfungsi di luar kotak. Pada masa ini versi terkini ialah: 602401143452.dkr.ecr.ap-southeast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
mempunyai masalah ini.
Terima kasih kepada semua orang yang membaca hingga akhir, uji semua yang anda akan gunakan dalam pengeluaran sebelum pelaksanaan.
Sumber: www.habr.com