Kubernetes Temelleri

Container orchestration kavramını, neden ihtiyaç duyduğumuzu ve bu alandaki bilinmesi gerekenleri açıklıyoruz.

Kubernetes'in ortaya çıkış hikayesi ve tarihçesini açıklıyoruz.

Kubernetes nedir? sorusuna geniş bir açıklama getiriyoruz.

Api-server, kube-scheduler vb. Kubernetes'i oluşturan temel komponentleri, bir fabrika anolojisi üstünden anlatıyoruz.

Kubernetes'i oluşturan tüm komponenetleri, neler olduklarını ve ne işe yaradıklarını açıklıyoruz.

Bu bölümde Kubernetes’in yayın döngüsünü yani ne sıklıkla yeni versiyon yayınlandığını ve destek süreçlerini anlatıyoruz.

Bizler Kubernetes clusterlar üzerinde işlem yapmak istediğimiz zaman, yani Kubernetes’e komut vermek istediğimiz zaman bunu api-server üzerinden yaparız. Bunu komut satırında kubectl aracını kullanarak gerçekleştirirz. Bu bölümde kubectl kurulumunu öğreneceğiz.

Merhaba arkadaşlar, bir önceki bölümde kubectl kurduk ve artık Kubernetes kurulumu yapabiliriz. Fakat öncelikle şu soruya bir cevap bulmamız gerekiyor. Hangi Kubernetes? Bu bölümde bunu yapacağız.

Bu bölümde Docker Desktop yazılımıyla birlikte gelen single node Kubernetes kurulumunu göstereceğiz.

Minikube Kubernetes projesi altında hizmet veren “Cluster Lifecycle Special Interest Group” tarafından oluşturulup yönetilen, test ve geliştirme için kendi bilgisayarlarınızda kurabileceğiniz bir Kubernetes dağıtımı. Bu bölümde detaylarını inceleyecek ve kurulumunu göstereceğiz.

Microsoft’un Cloud platformu Azure’un sunduğu yönetilen Kubernetes hizmeti Azure Kubernetes Service ya da kısaca AKS kurulum işlemlerini göreceğiz.

Bu bölümde Google Cloud’un yönetilen Kubernetes hizmeti Google Kubernetes Engine, nam-ı diğer GKE kurulumu ile devam edeceğiz.

AWS'in yönetilen Kubernetes servisi olan EKS kurulum detaylarını öğreneceğiz.

Kubeadm best-practiceler takip edilerek hızlı şekilde ve gerekli olan minumum konfigürasyonla Kubernetes cluster kurulumu sağlayan bir araçtır. Bu bölümde detaylarını göreceğiz.

Play-with-kubernetes, Docker firması tarafından sağlanan ve bizlerin web browserlar üzerinden kullanabileceğimiz bir Kubernetes cluster oluşturmamıza imkan veren çok hoş bir araç. Bu bölümde detaylarını öğreneceğiz.

kubectl aracının mevcut bir Kubernetes cluster ile iletişim kurması için nasıl ayarlanabileceğini öğreneceğiz.

kubectl aracının kulllanımını ve bilmemiz gereken parametreleri öğreneceğiz.

En temel Kubernetes objesi olan Pod'lara göz atacak ve bu obje etrafından Kubernetes'i daha yakından tanımaya başlayacağız.

Bu bölümde Pod objesini imperative olarak oluşturmayı öğreneceğiz.

YAML nedir, ne neden öğrenmemiz gerekiyor ve Kubernetes ile ilişkisi nedir sorularına bir cevap bulacağız.

Declarative şekilde pod oluşturmayı ve Kubernetes objelerini oluşturabileceğimiz yaml dosyaları hakkında bilgiler öğreniyoruz.

Daha önce pod oluşturulduğu zaman neler oluyor sorusuna kısa da olsa bir cevap vermiştik. Bu bölümde bu cevabı biraz daha açacak ve pod’un yaşam döngüsünde nasıl bir yol izlediğini göreceğiz. İlk olarak işin teorik kısmını halledeceğiz.

Bu bölümde bir önceki bölümde öğrendiklerimizi uygulamalı olarak göreceğiz.

Daha önce bir pod içerisinde birden fazla container oluşturabileceğimiz bilgisini vermiş ama şimdilik bunu bir süre unutmanızı ve önemsememenizi söylemiştim. O bir süre sona erdi. Bu bölümde multi-container konusuna dalıyoruz.

Bir önceki bölümde pod içerisinde birden fazla container çalıştırmaya neden ihtiyaç duyabileceğimizi ve hangi durumlarda kullanıldığını öğrendik. Şimdi sırada bunu nasıl yapabileceğimiz var.

Bir pod içinde birden fazla container çalıştırmanın nedenlerini ve bunu nasıl yapabileceğimizi önceki bölümlerde öğrendik. Şu ana kadar öğrendiğimiz yöntem pod içerisinde iki container çalıştırıp her ikisinin de pod’un yaşam süresi boyunca çalışmaya devam ettiği yöntemdi. Ama pod içerisinde birden fazla container çalıştırmanın başka bir yöntemi daha var ve biz buna init container diyoruz. Bu bölümde bunu öğreneceğiz.

Kubernetes’deki önemli konseptlerden biri olan label yani etiket ve selector yani etiket seçme konusuyla devam ediyoruz.

Bir önceki bölümde teoride gördüğümüz label konusunu bu bölümde uygulamalı olarak öğreneceğiz.

Objelere metadata eklemek için kullanabildiğimiz bir opsiyon olan label’ları önceki iki bölümde işledik. Fakat labellar elimizdeki tek seçenek değil. Aynen label gibi anahtar veri eşlenikleri şeklinde metadata ekleyebileceğimiz bir opsiyon daha var ve bu da annotations. Bu bölümde işleyeceğimiz konu da bu annotation oluyor.

Kubernetes’in en temel yapılarından biri olan namespace konusu ile devam ediyoruz.

Bizler genelde Kubernetes üstünde singleton olarak adlandırdığımız tekil, yönetilmeyen podlar yaratmayız. Podları yöneten üst seviye objeler yaratırız ve podlar bu objeler tarafından yaratılıp yönetilir. İşte bu bölümde bu objelerin en sık kullanılanlarından biri olan Deployment objesine göz atacağız.

Deployment objesini uygulayarak öğreniyoruz.

Önceki bölümlerde deployment objesini tanıdık ve nasıl oluşturulduğunu gördük. Ne dedik? Bizler podları direkt yaratmaz bunun yerine deployment gibi daha üst seviye objeler kullanırız ve bu objeler istediğimiz özelliklerde podlar yaratır. İşte bu üst seviye objelerden ReplicaSet ile devam ediyoruz.

Deployment ve replicaset objelerini ve aralarındaki ilişkiyi gördük ama deployment’i deployment yapan rollout özelliklerine değinmedik. Bu bölümde bunu yapacağız.

Kubernetes'in ağ altyapısında özellikle egress tarafından neler oluyor bunu öğreniyoruz.

Pod'larımızda healthcheck yani sağlık kontrolü yapma imkanı sağlayan liveness probe konusunu işliyoruz.

Bir pod'un service arkasına alınmaya hazır olup olmadığına otomatik karar verilmesini sağlayan readiness probe tanımlarını görüyoruz.

Pod'larımızın cpu ve memory kaynaklarını kısıtlı erişimini nasıl sağlayabileceğimizi öğreniyoruz.

Bu bölümde containerlarla ilgili önemli konulardan biri olan "enviroment variable" konusuna göz atacak ve bunu Kubernetes içerisinde nasıl tanımlayabildiğimizi göreceğiz.

Verilerimizi container'ın yaşam süresinden daha uzun süre saklama imkanı sunan Volume konusuyla devam ediyoruz.

Secretlar kullanıcı adı şifreler, tokenlar ya da ssh anahtarları gibi hassas bilgileri depolamanıza ve yönetmemize olanak sağlayan kubernetes objeleridir. Bu bölümde bu konuya göz atıyoruz.

Bu bölümde bir önceki bölümde gördüğümüz secret objeleriyle birebir aynı şekilde oluşturulan ve aynı işe yarayan configmap objesini işliyor ve farklarını öğreniyoruz.

Bu bölümde podlarımızın uygun worker node’lar üstünde oluşturulması için kullanabileceğimiz ve nodeSelector’den daha fazla opsiyon sunan node affinity konusuna göz atacağız.

Bir önceki bölümde bir pod’un uygun worker node üstünde Schedule edilebilmesi için kullanabileceğimiz seçeneklerden biri olan node affinity tanımlarını gördük. Fakat bazı durumlarda bize bu yetmiyor. Bazı durumlarda bizler oluşturduğumuz pod’un Schedule edeceği node’un üstüne çalışan başka podların olması ya da olmaması durumuna göre seçilmesini isteyebiliriz. Bunu da pod affinity ile sağlıyoruz.

Node ve pod affinity konularında bir pod’un hangi node üstünde schedule edileceği ile ilgili tanımları gördük. Fakat bu işi pod merkezli halletmek bazı durumlarda yeterli gelmiyor. İşte bu yeterli gelmeyen usecaseleri de çözebileceğimiz taint ve toleration ayarları var ve biz de bu bölümde bunları göreceğiz.

Log collector uygulamaları ya da storage device agentları gibi cluster üstünde her node'da deploy etmeniz gereken uygulamaları deploy etmenizi kolaylaştıran DaemonSet objesini inceliyoruz.

Verilerimizi Pod'un yaşam süresinden daha üzün süre saklama imkanı sunan Persistent Volume ve bunları pod'lara bağlamaya yaran Persistent Volume Claim konusunu işliyoruz.

Bir önceki bölümde teorisini gördüğümüz Persistent Volume ve Persistent Volume Claim konusunun uygulamasıyla devam ediyoruz.

Persistent Volume oluşturmayı dinamik olarak halledebilmemize imkan sağlayan storage class ayarlarını öğreniyoruz.

Stateful uygulamalarımızı şu ana kadar gördüğümüz hiçbir obje tipiyle düzgün yönetme imkanına sahip değildir. StatefulSet objesi bu durumu değiştiriyor.

Şu ana kadar işlediğimiz tüm controllerların “deployment, replicaset, daemonset ve statefulset” tamamı müdahele edilip kapatılmadığı sürece çalışmaya devam etmesi gereken uygulamalarla ilgiliydi. Fakat bazı iş yüklerimiz bu şekilde uzun süre çalışması gereken uygulamalar değiller. Çalıştırılıp işini yapıp kapanması gereken de birçok uygulamamız var. Bunları job objeleri olarak oluşturuyoruz.

Bir job objesini manuel başlatmak yerine örneğin her gün saat 2 de ya da her Pazar 12’de ya da her beş dakikada bir çalışacak şekilde schedule etmek isteseydik ne olacaktı? Tam da tahmin ettiğiniz üzere bunun için de bir objemiz var ve adı da CronJob.

Bu bölümden başlayarak önümüzdeki birkaç bölüm boyunca Kubernetes authentication, authorization yani kimlik doğrulama ve yetkilendirme konularını ve bununla bağlantılı olarak da kullanıcı hesaplarını göreceğiz.

Kubernetes yetkilendirme işlemlerini Role based Access control, kısaca rbac yani rol tabanlı erişim kontrolü methoduna göre gerçekleştirir. RBAC kısacası yetki ve rollerin tanımlanması ve bu tanımlanmış yetki ve rollerin kimliği doğrulanmış objelere atanması prensibine göre tanımların.

Pod içerisinde deploy ettiğimiz uygulamaların jwt Bearer Token'leri kullanarak Kubernetes api-server ile haberleşebilmelerine imkan sağlayan Service Account objesini işliyoruz.

Service bölümünde uygulamalarımızın dış dünyadan erişilebilmesi için NodePort ve LoadBalancer tipinde servislere sahip olduğumuzu görmüş ve bunların detaylarını işlemiştik. Fakat bu yöntemlerin ikisi de OSI Layer 4’da yani ip layerinda çalıştıkları için bizlerin bazı sorunlarını çözmüyor. Bu sorunları L7'de çalışan Ingress ile çözüyoruz.

Eğitimde öğrendiklerimizi uygulayabileceğimiz bir gerçek hayat senaryosunu adım adım uygulamaya başlıyoruz. Bu ilk bölümde projede sizlerden neler beklendiğini anlatıyorum.

Projenin nasıl oluşturulabileceğini adım adım görüyoruz.

Projenin nasıl oluşturulabileceğini adım adım görüyoruz.

Projenin nasıl oluşturulabileceğini adım adım görüyoruz.

Projenin nasıl oluşturulabileceğini adım adım görüyoruz.

Eğitimin sonuna geldik. Hoşçakalın arkadaşlar.