Yolculuk’taki ilk durağın bir CI kümesi olması gerektiğine karar veren ekip, plan taslaklarını hazırlamaya başladı. Oraya nasıl gidecekleri, ne tür bir temel altyapıya ihtiyaç duyacakları, her Konteynerin nasıl yükleneceği ve yürütüleceği ve Yolculuk sırasında stres seviyelerinin mümkün olduğunca düşük tutulmasını hangi araçların sağlayacağına dair planlar.
Ancak Yolculuğun fiilen başlaması aynı yılın Eylül ayına kadar mümkün olmayacaktı. Yalnızca birkaç gün içinde bir yönetim ArgoCD kümesi ve birçok yeni VPC oluşturuldu, VPN VPC’lerle eşleme bağlantıları kuruldu ve Datadog Agent ve Fluent Bit gibi araçlardan oluşan “kargo” kümeye yüklendi. Böylece EKS (Elastik Kubernetes Hizmeti) yola çıkmaya hazırdı! Tesadüfen, maceraya susamış bir şekilde HackerOne’a geldiğim sıralardaydı.
Dümendeki İlk Birkaç Gün
Önümüzdeki zorluk devasa görünmeye başladığında limanın hemen dışındaydık! GitLab Runner’lar Kubernetes kümesine doğru şekilde nasıl kurulur ve ihtiyaç duydukları tüm izinlere sahip olduklarından nasıl emin olabiliriz? Bu yeni ve sonsuz manzarada doğru navigasyon tekniklerine ihtiyacımız vardı.
İlk başta, birbirine yapıştırılması gereken tüm farklı bileşenler hakkında daha derin bir anlayış elde ederek fayda sağlayabilmek için bunu manuel olarak ayarlamayı denememiz gerektiğini düşündük; Container’lar, Pod’lar, IAM rolleri, EC2 bulut sunucuları, Kubernetes RBAC ve daha fazlası. Birkaç gün boyunca konuyu farklı açılardan ele almaya çalışarak ve yürüttüğümüz tüm deneylerin notlarını tutarak daireler çizerek dolaştık.
Biraz ama çok az ilerleme kaydettikten sonra bitkin ve hayal kırıklığına uğradık. Şöyle düşündüğümü hatırlıyorum: “Basit bir GitLab Runner Container oluşturmak bu kadar zor olmamalı! Bunu daha önce de yapmıştım, bu ideal değil.”
Böylece odak noktamızı değiştirdik. “Buna başından beri yanlış bakıyorduk!” diye sonuca vardık. “Sadece resmi Dümen Tablosunu kullanmalıyız” dedik ve manüel işleri GitLab’ın sağladığı şeye devrederek hayatımızı kolaylaştırmaya karar verdik ve tüm topluluk zaten kullanıyor.
Yeniden gruplaştık, toplandık ve ikili program yaptık. Doğaçlama Slack toplantılarının derinliklerine daldık, Zoom toplantılarını önceden ayarladık ve birçok not alıp tüm ekibe aktardık. Hızla ilerleme görmeye başladık. Birkaç gün sonra ilk Runner’ımızı hazır hale getirdik. Birkaç gün sonra yeni Runner’ımızı mümkün olduğunca güvenli hale getirmeye başladık. Döndükten iki hafta sonra altyapı deposundan Kubernetes üzerinde çalışan ilk işimizi yaptık. Gerekli belgeleri yazdık, şampanyayı açtık ve birkaç gün dinlendik.
Rüzgarı Yakalamak
Bir süre sonra merak etmeye başladık. Elbette evet, basit işleri yürütebilecek eksiksiz ve güvenli bir GitLab Runner oluşturmayı başardık. Ama denize uygun muydu? Cevabın hayır olduğunu biliyorduk. Daha iyi, daha büyük, Core projesinin karmaşık işlerini alıp yarın yokmuş gibi yürütecek bir şey bulmalıydık.
Böylece başka bir Runner yarattık. Bu neredeyse aynıydı ama ilkine eşit yaratılmamıştı. Karmaşık işleri yürütebilecek şekilde tasarlandı ve bu nedenle daha fazla ayrıcalığa sahipti. Elbette her iki Runner’ı da elimizde tutacağız çünkü her biri farklı bir amaca hizmet edecek.
Ve sonra operasyonlarımızı ölçeklendirmeye bakmanın zamanı geldi. Core projesinin tek bir MR (Birleştirme İsteği) işlem hattı, yaklaşık 170’i aynı anda başlayan 180’den fazla işi çalıştırır. Bu işlerin her biri bir Kubernetes Pod’a dönüşür. Bu Pod’ların tümü, Düğümlerin (EC2 bulut sunucuları) sağladığı CPU ve Belleğe ihtiyaç duyar. Üstelik sıklıkla 6 veya daha fazla boru hattının aynı anda çalıştığını gözlemledik. Dolayısıyla, bir sonraki zorluğumuz açıktı: Çok önemli bir şekilde, bir işlem hattı başladığında ölçeği hızlı bir şekilde artan ve aynı derecede önemli olarak, hiçbir iş çalışmadığında ölçeği küçülen bilgi işlem gücünü nasıl sağlayabiliriz? Ekip olarak hedeflerimizden biri, performans sorunlarına para harcamak yerine her zaman altyapımızı optimize etmek olmuştur.
Kümemize bir araç daha eklemeye karar verdik; Marangoz. Karpenter o zamanlar ön beta aşamasında olsa bile oldukça umut verici görünüyordu ve topluluk, mimari kararlarının yanı sıra AWS ile kusursuz entegrasyonu nedeniyle zaten onu büyük bir değer görmeye başlamıştı. Bir dakikadan daha kısa bir sürede yeni Düğümler oluşturabilir ve ölçeklendirmeyi kalbimizin arzularına göre ayarlamamıza olanak tanır. Ancak yine de onu en son beta sürümüne yükseltmekte zorluk yaşadık; bu, Altyapı Mühendisleri olarak tüm araçları güncel tutmak için bitmek bilmeyen çabalarımızda sık sık karşılaştığımız zorluklardan biri, çünkü hatalar sıklıkla ortaya çıkıyor ve ardından yamalanıyor. sonraki küçük sürüm güncellemelerinde.
Sonunda, modernleştirilmiş bir CI yolculuğumuza iki ay kala, EKS kümemizi, GitLab Çalıştırıcılarını, Düğümleri talebe göre büyütüp küçülttük ve ayrıca buna uygun iyi belgelerimiz de vardı. Ufukta kara gördük. Kısa bir mola verip limana doğru yola çıkmanın zamanı gelmişti. Avast siz pislikler! Denizin uzun süre sakin kalması beklenemezdi!
Fırtına Öncesi Sessizlik ve Sakinlik Öncesi Fırtına
Noel tatilimize yaklaşırken hepimiz sakin denizlerin özlemini çekiyorduk. Ancak seçtiğimiz hayat bu değil. Ve ufukta bir fırtına yaklaşıyordu; fikri mülkiyet tükenmesi! İlk tasarımımızda gözden kaçırdığımız küçük bir şeyin kümemizde sorun yarattığı ortaya çıktı. Tutumlu olmaya çalışarak, iki alt ağında yalnızca birkaç kullanılabilir IP bulunan küçük bir VPC oluşturduk, ancak artık yüzlerce Düğüme ve binlerce Pod’a ölçeklendirmek istediğimiz için dağıtılacak yeterli IP yoktu. Tüm kümeyi yeniden yaratmak zorunda kaldık!
Kulağa korkutucu gelebilir ama denizde ayaklarımızı uzun zaman önce bulduğumuzdan, IaC’de her şeyimiz vardı. Terraform, Helm Chart yapılandırması veya düz YAML bildirimleri olsun, her şey belgelenmiştir ve hakemli koddur. Böylece, yarım gün içinde tüm VPC’yi, eşleme bağlantılarını ve araçlarıyla birlikte tüm EKS kümesini çalışır duruma getirmeyi başardık! Bu, kaydettiğimiz ilerlemenin bir onayıydı.
Fırtınayı yara almadan ve tertemiz bir şekilde atlattık. Önümüzdeki birkaç hafta boyunca, dördüncü çeyreğin üçüncü ayına yaklaştığımız ve OKR’lerin bitiş çizgisini geçmesi gerektiği için dikkatimizi diğer acil konulara kaydırdık.
Limanda Yaşam
Kış tatilleri gelip geçti ve hepimiz birkaç gün dinlenmeyi başardık. Yenilenen coşku ve ruhla Core’un işlerini yavaş ama emin adımlarla Kubernetes Runners’a yüklemeye başladık. MR’dan sonra MR, geliştirme şubesiyle birleştirildi ve çok geçmeden biz de neredeyse OKR’mize ulaştık.
Limana yanaştık ama dinlenmedik. Bizi az önce atlattığı uzun yolculuktan sonra gemimizde bakım yapmamız gerektiğini biliyorduk. EKS kümesi ve bileşenleri için uyarılar oluşturduk. Bu uyarılarla birlikte olay müdahale taktik kitapları yazdık. Araçlarımızı güncel tuttuğumuzdan emin olmak için bir yama yönetimi prosedürü yazdık. Yolculuğumuz sırasında öğrendiklerimizi konuyla ilgilenen herkese kolayca yaymak için daha da fazla belge yazdık; sorun giderme kılavuzları, kavramların açıklamaları, kararların ardındaki mantık ve daha fazlası.
Daha sonra düzeltmeler yapmaya da başladık. Kurulumun çalışma davranışını sürekli inceleyerek tasarımımızda delikler bulduk. Evet, kümenin performansını ölçtük ve inceledik ve memnun kaldık, ancak kendimizi ve şirket altyapımızı geliştirmeye devam etmek için sürekli bir geri bildirim döngüsüne de güveniyoruz. Amacımız ince, formda ve performanslı bir yapıya sahip olmaktır.
Maliyetleri daha da azaltmak ve aynı zamanda boru hattı süresini kısaltmak için Karpenter konfigürasyonlarımızı bir kez daha revize ettik. Bunu, Core projesinin işlem hattındaki işlere dayalı olarak örnekleri doğru boyutlandırarak ve aynı zamanda işlerin kendilerini de doğru hale getirerek, onlara yeterli CPU ve Bellek ayırarak yaptık. Bu, Düğümlerimizin iş yüklerini daha verimli bir şekilde ele almasını sağladı. Yani artık CPU ve Bellek kullanımları orantılı olarak artıyor ve Düğümler kapasitelerinin maksimumunda kullanılıyor.
Çok sayıda kesin hesaplama gerektiren kaynak tahsisi (CPU ve Bellek) ile ilgili tamamen yeni ve heyecan verici sorunlarla ve ENA (Elastik Ağ Adaptörü) arayüzlerinin ağ bant genişliği limitleriyle ilgili diğer sorunlarla, AWS kapasite planlama stratejilerinin derinliklerine dalmamızı sağladık.
Daha yüksek standartta bir Geliştirici Deneyimi ve hataya daha dayanıklı bir kurulum sağlamak için hâlâ yapmak istediğimiz birkaç şey var ve bunlar üzerinde yorulmadan çalışıyoruz.
Ancak iş kuyruğuna girme süresinin azaldığını gözlemledik. Ortalama iş süresinin de azaldığını gözlemledik. Birkaç düzeltme ve iyileştirme turundan sonra günlük AWS maliyetleri de düşmeye başladı ve eski koşucuların ortalama günlük maliyetlerinden daha az oldu.
Böylece biz de hedeflerimize ve OKR’ye neredeyse farkına bile varmadan ulaştık. Acı tatlı hissettik. Bir Yolculuk sona ermişti.
Macera Özlemi
Zaten bir aydır bağlantıda olsak ve hâlâ sadece CI kümemizi değil tüm platformu onarmak ve geliştirmekle meşgul olsak da, maceraya olan özlemimiz kulaklarımıza fısıldıyor.
Yolculuğumuzu anıyoruz, bunun zor ve öngörülemez bir yolculuk olduğunun farkına varıyoruz. Tamamen yeni, devasa ve modern bir konunun derinliklerine dalmakla kalmadık, aynı zamanda ilk durak olarak CI kümesini seçtik. Kelimenin tam anlamıyla Düğümler açısından 0’dan 100’e anında ölçeklenmesi gereken CI kümesi. Birden fazla türde iş yükünü işleyen CI kümesinin bu nedenle ekstra güvenli olması gerekir. Yoğun zamanlarda, gelecekte oluşturacağımız diğer kümelerden daha fazla Kapsül’e sahip olacak olan CI kümesi, hatta muhtemelen birleştirilmiş olacaktır.
Ancak şimdi düşününce ve bu zorlu mücadeleyi iyi bir şekilde atlattığımızın farkına vararak, cesurca yeniden ufuklara bakıyoruz. CI kümemize yalnızca daha fazla iş ve boru hattı değil, aynı zamanda heyecan verici yeni fikirler, metodolojiler ve araçlar da getiren ufuklar!
Keşfedilecek ne olduğunu biliyoruz: Verimliliği daha da artıracak ve maliyetleri düşürecek Graviton bulut sunucuları ve ARM mimarisi, kuyruk boyutu veya gecikme gibi hassas ölçümlere dayalı yatay otomatik ölçeklendirme, gelişmiş sürüm için yeşil-mavi ve kanarya dağıtımları, dinamik geliştirme ortamları yazılım geliştirmeyi, kaynak kullanımına dayalı dikey otomatik ölçeklendirmeyi, giriş denetleyicilerini ve ek güvenlik kısıtlamaları için hizmet ağlarını ve çok daha fazlasını etkinleştirin.
Bir sonraki Kubernetes yolculuğunun da zorlu olacağını biliyoruz. Ve ondan sonrakini de. Ancak bu zorlukların üstesinden gelme konusunda kendimize güveniyoruz ve ekip çalışmamıza, istekliliğimize ve bunların üstesinden gelmek için derin çalışma yeteneğimize güveniyoruz.
Gemimize bir kez daha binmeyi, yelkenleri açmayı, direklere tırmanmayı ve uçsuz bucaksız teknoloji okyanusunun karşımıza çıkaracağı şeylerle yüzleşmeyi sabırsızlıkla bekliyoruz.
Yakında tekrar yola çıkacağız ve herkesi gemimize davet ediyoruz.