Selamat siang, saya ingin berbagi dengan Anda pengalaman saya dalam menyiapkan dan menggunakan layanan AWS EKS (Elastic Kubernetes Service) untuk container Windows, atau lebih tepatnya tentang ketidakmungkinan menggunakannya, dan bug yang ditemukan di container sistem AWS, bagi mereka yang tertarik dengan layanan ini untuk container Windows, silakan di bawah cat.
Saya tahu bahwa container Windows bukanlah topik yang populer, dan hanya sedikit orang yang menggunakannya, namun saya tetap memutuskan untuk menulis artikel ini, karena ada beberapa artikel tentang Habré di kubernetes dan Windows dan masih ada orang seperti itu.
awal
Semuanya bermula ketika diputuskan untuk memigrasikan layanan di perusahaan kami ke kubernetes, yaitu 70% Windows dan 30% Linux. Untuk tujuan ini, layanan cloud AWS EKS dianggap sebagai salah satu opsi yang memungkinkan. Hingga 8 Oktober 2019, AWS EKS Windows berada dalam Pratinjau Publik, saya memulainya, kubernet versi 1.11 yang lama digunakan di sana, tetapi saya memutuskan untuk tetap memeriksanya dan melihat pada tahap apa layanan cloud ini, apakah itu berfungsi sama sekali, ternyata tidak, itu adalah bug dengan penambahan penghapusan pod, sementara yang lama berhenti merespons melalui ip internal dari subnet yang sama dengan node pekerja windows.
Oleh karena itu, diputuskan untuk meninggalkan penggunaan AWS EKS demi cluster kami sendiri di kubernetes pada EC2 yang sama, hanya saja kami harus menjelaskan sendiri semua penyeimbangan dan HA melalui CloudFormation.
Dukungan Kontainer Windows Amazon EKS kini Tersedia Secara Umum
oleh Martin Beeby | pada 08 Oktober 2019
Sebelum saya sempat menambahkan template ke CloudFormation untuk cluster saya sendiri, saya melihat berita ini
Tentu saja, saya mengesampingkan semua pekerjaan saya dan mulai mempelajari apa yang mereka lakukan untuk GA, dan bagaimana segalanya berubah dengan Pratinjau Publik. Ya, AWS, bagus sekali, memperbarui gambar untuk node pekerja windows ke versi 1.14, serta cluster itu sendiri, versi 1.14 di EKS, sekarang mendukung node windows. Proyek oleh Pratinjau Publik di Mereka menutupinya dan berkata sekarang gunakan dokumentasi resmi di sini:
Mengintegrasikan klaster EKS ke dalam VPC dan subnet saat ini
Di semua sumber, di tautan di atas pada pengumuman serta dalam dokumentasi, diusulkan untuk menerapkan klaster baik melalui utilitas eksctl berpemilik atau melalui CloudFormation + kubectl setelahnya, hanya menggunakan subnet publik di Amazon, serta membuat a pisahkan VPC untuk klaster baru.
Opsi ini tidak cocok untuk banyak orang; pertama, VPC terpisah berarti biaya tambahan + lalu lintas peering ke VPC Anda saat ini. Apa yang harus dilakukan oleh mereka yang sudah memiliki infrastruktur siap pakai di AWS dengan Beberapa akun AWS, VPC, subnet, tabel rute, gateway transit, dan sebagainya? Tentu saja, Anda tidak ingin merusak atau mengulang semua ini, dan Anda perlu mengintegrasikan klaster EKS baru ke dalam infrastruktur jaringan saat ini, menggunakan VPC yang ada dan, untuk pemisahan, paling banyak membuat subnet baru untuk klaster tersebut.
Dalam kasus saya, jalur ini dipilih, saya menggunakan VPC yang ada, hanya menambahkan 2 subnet publik dan 2 subnet pribadi untuk cluster baru, tentu saja semua aturan diperhitungkan sesuai dengan dokumentasi .
Ada juga satu syarat: tidak ada node pekerja di subnet publik yang menggunakan EIP.
eksctl vs CloudFormation
Saya akan segera membuat reservasi bahwa saya mencoba kedua metode penerapan cluster, dalam kedua kasus gambarannya sama.
Saya akan menunjukkan contoh hanya menggunakan eksctl karena kode di sini akan lebih pendek. Menggunakan eksctl, terapkan cluster dalam 3 langkah:
1. Kami membuat cluster itu sendiri + node pekerja Linux, yang nantinya akan menjadi host container sistem dan pengontrol vpc yang bernasib buruk itu.
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 menerapkan ke VPC yang sudah ada, cukup tentukan id subnet Anda, dan eksctl akan menentukan VPC itu sendiri.
Untuk memastikan bahwa simpul pekerja Anda disebarkan hanya ke subnet privat, Anda perlu menentukan --node-private-networking untuk nodegroup.
2. Kami menginstal vpc-controller di cluster kami, yang kemudian akan memproses node pekerja kami, menghitung jumlah alamat IP gratis, serta jumlah ENI pada instance, menambah dan menghapusnya.
eksctl utils install-vpc-controllers --name yyy --approve3.Setelah container sistem Anda berhasil diluncurkan di node pekerja Linux Anda, termasuk vpc-controller, yang tersisa hanyalah membuat grup node lain dengan pekerja 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-networkingSetelah node Anda berhasil terhubung ke cluster Anda dan semuanya tampak baik-baik saja, node tersebut berada dalam status Siap, tetapi tidak.
Kesalahan pada pengontrol vpc
Jika kita mencoba menjalankan pod pada node pekerja windows, kita akan mendapatkan error:
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 bahwa instance kita di AWS terlihat seperti ini:
Dan seharusnya seperti ini:
Dari sini jelas bahwa pengontrol vpc tidak memenuhi perannya karena alasan tertentu dan tidak dapat menambahkan alamat IP baru ke instance sehingga pod dapat menggunakannya.
Mari kita lihat log dari pod vpc-controller 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.Pencarian di Google tidak menghasilkan apa-apa, karena rupanya belum ada yang menemukan bug tersebut, atau belum memposting masalah tersebut, saya harus memikirkan opsinya sendiri terlebih dahulu. Hal pertama yang terlintas dalam pikiran adalah mungkin pengontrol vpc tidak dapat menyelesaikan ip-10-xxx.ap-xxx.compute.internal dan mencapainya sehingga terjadi kesalahan.
Ya, memang, kami menggunakan server DNS khusus di VPC dan, pada prinsipnya, kami tidak menggunakan server Amazon, sehingga penerusan pun tidak dikonfigurasi untuk domain ap-xxx.compute.internal ini. Saya menguji opsi ini, dan tidak membuahkan hasil, mungkin pengujiannya tidak bersih, dan oleh karena itu, lebih jauh lagi, ketika berkomunikasi dengan dukungan teknis, saya menyerah pada ide mereka.
Karena sebenarnya belum ada ide, semua security group dibuat oleh eksctl sendiri, jadi servicenya tidak diragukan lagi, tabel rutenya juga benar, nat, dns, akses internet dengan node pekerja juga ada.
Selain itu, jika Anda men-deploy node pekerja ke subnet publik tanpa menggunakan —node-private-networking, node ini segera diperbarui oleh pengontrol vpc dan semuanya berjalan seperti jarum jam.
Ada dua pilihan:
- Menyerahlah dan tunggu sampai seseorang menjelaskan bug ini di AWS dan mereka memperbaikinya, lalu Anda dapat menggunakan AWS EKS Windows dengan aman, karena mereka baru saja dirilis di GA (8 hari telah berlalu pada saat artikel ini ditulis), banyak yang mungkin akan melakukannya ikuti jalan yang sama dengan saya.
- Tulis ke AWS Support dan beri tahu mereka inti masalahnya dengan sejumlah besar log dari mana saja dan buktikan kepada mereka bahwa layanan mereka tidak berfungsi saat menggunakan VPC dan subnet Anda, bukan tanpa alasan kami memiliki dukungan Bisnis, Anda harus menggunakan setidaknya sekali :)
Komunikasi dengan teknisi AWS
Setelah membuat tiket di portal, saya secara keliru memilih untuk merespons saya melalui Web - email atau pusat dukungan, melalui opsi ini mereka dapat menjawab Anda setelah beberapa hari, meskipun faktanya tiket saya memiliki Keparahan - Gangguan sistem, yang mana berarti respons dalam waktu <12 jam, dan karena paket dukungan Bisnis memiliki dukungan 24/7, saya mengharapkan yang terbaik, namun ternyata seperti biasa.
Tiket saya tidak ditetapkan dari hari Jumat hingga Senin, lalu saya memutuskan untuk menulis surat kepada mereka lagi dan memilih opsi tanggapan Obrolan. Setelah menunggu beberapa saat, Harshad Madhav ditunjuk untuk menemui saya, dan kemudian dimulai...
Kami melakukan debug secara online selama 3 jam berturut-turut, mentransfer log, menerapkan cluster yang sama di laboratorium AWS untuk meniru masalah, membuat ulang cluster di pihak saya, dan seterusnya, satu-satunya hal yang kami dapatkan adalah dari lognya jelas bahwa resol tidak berfungsi Nama domain internal AWS, yang saya tulis di atas, dan Harshad Madhav meminta saya untuk membuat penerusan, diduga kami menggunakan DNS khusus dan ini bisa menjadi masalah.
Ekspedisi
ap-xxx.compute.internal -> 10.x.x.2 (VPC CIDRBlock)
amazonaws.com -> 10.x.x.2 (VPC CIDRBlock)Itulah yang telah dilakukan, hari telah berakhir Harshad Madhav menulis kembali untuk memeriksanya dan seharusnya berhasil, tetapi tidak, resolusi tersebut tidak membantu sama sekali.
Lalu ada komunikasi dengan 2 insinyur lagi, yang satu keluar dari obrolan, rupanya dia takut dengan kasus yang rumit, yang kedua menghabiskan hari saya lagi pada siklus penuh debugging, mengirim log, membuat cluster di kedua sisi, di akhirnya dia hanya berkata baik, itu berhasil untuk saya, inilah saya, saya melakukan semuanya langkah demi langkah dalam dokumentasi resmi dan Anda dan Anda akan berhasil.
Yang mana saya dengan sopan memintanya untuk pergi dan menugaskan orang lain ke tiket saya jika Anda tidak tahu di mana mencari masalahnya.
Final
Pada hari ketiga, seorang insinyur baru Arun B. ditugaskan kepada saya, dan sejak awal komunikasi dengannya, terlihat jelas bahwa ini bukan 3 insinyur sebelumnya. Dia membaca seluruh sejarah dan segera meminta untuk mengumpulkan log menggunakan skrip ps1 miliknya sendiri, yang ada di github-nya. Ini diikuti lagi dengan semua iterasi dalam membuat cluster, mengeluarkan hasil perintah, mengumpulkan log, tetapi Arun B. bergerak ke arah yang benar dilihat dari pertanyaan yang diajukan kepada saya.
Kapan kita sampai mengaktifkan -stderrthreshold=debug di vpc-controllernya, dan apa yang terjadi selanjutnya? tentu saja tidak berhasil) pod tidak dimulai dengan opsi ini, hanya -stderrthreshold=info yang berfungsi.
Kami selesai di sini dan Arun B. mengatakan bahwa dia akan mencoba mengulangi langkah-langkah saya untuk mendapatkan kesalahan yang sama. Keesokan harinya saya menerima tanggapan dari Arun B. dia tidak meninggalkan kasus ini, tetapi mengambil kode ulasan pengontrol vpc mereka dan menemukan tempatnya dan mengapa tidak berfungsi:
Jadi, jika Anda menggunakan tabel rute utama di VPC Anda, maka secara default tabel tersebut tidak memiliki asosiasi dengan subnet yang diperlukan, yang sangat diperlukan untuk pengontrol vpc, dalam kasus subnet publik, ia memiliki tabel rute khusus yang mempunyai asosiasi.
Dengan menambahkan asosiasi secara manual untuk tabel rute utama dengan subnet yang diperlukan, dan membuat ulang grup node, semuanya berfungsi dengan sempurna.
Saya berharap Arun B. benar-benar melaporkan bug ini kepada pengembang EKS dan kita akan melihat versi baru dari vpc-controller di mana semuanya akan berjalan dengan baik. Saat ini versi terbaru adalah: 602401143452.dkr.ecr.ap-southeast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
memiliki masalah ini.
Terima kasih kepada semua orang yang membaca sampai akhir, uji semua yang akan Anda gunakan dalam produksi sebelum implementasi.
Sumber: www.habr.com