Tüm Bulut Türleri Üzerine Söyleşiler

Sistem ve Bulut Teknolojileri

Tag Archives: AKS

Azure AKS: Pod İçerisindeki Container Logları Nasıl İncelenir?

Posted on by Posted in Genel Leave a comment

Bir Kubernetes cluster’ı yönetirken, özellikle hata durumlarını teşhis etmek ve uygulama davranışlarını anlamak için en kritik araçlarımızdan biri loglardır. Pod içerisinde koşan container’ların ürettiği loglar, sistem yöneticileri ve DevOps mühendisleri için sorun giderme (troubleshooting) sürecinin başlangıç noktasıdır.

Bu makalede, AKS üzerinde çalışan mynginx veya aspnetapp gibi pod’ların loglarını komut satırı ve portal üzerinden nasıl inceleyebileceğimizi göreceğiz.

Adım 1: Pod İsimlerini Tespit Etme

Loglarını incelemek istediğimiz pod’un tam ismini bilmemiz gerekir. Bunun için mevcut pod’ları listeleyerek işe başlıyoruz:

Bash

kubectl get pods

[RESİM 1: kubectl get pods komut çıktısı]

Azure Portal üzerinden ilerlemek isterseniz, ilgili AKS cluster’ı içerisinde Workloads > Pods sekmesine giderek tüm pod listesine ve durumlarına ulaşabilirsiniz.

[RESİM 2: Azure Portal – Workloads/Pods ekranı]

Adım 2: kubectl logs Komutu ile Logları Görüntüleme

Bir pod içerisindeki container’ın loglarına erişmek için kubectl logs komutu kullanılır. Temel kullanımı şu şekildedir:

Bash

kubectl logs <pod-ismi>

Örneğin, mynginx pod’unun loglarını incelemek için:

Bash

kubectl logs mynginx

[RESİM 3: kubectl logs mynginx çıktısı ve uygulama logları]

Bu komutu çalıştırdığınızda, container içerisindeki uygulamanın (bu örnekte Nginx) ürettiği standart çıktıları (stdout) ve hataları (stderr) ekranda görebilirsiniz.

Adım 3: Logları Canlı Olarak Takip Etme

Hata anını yakalamak veya uygulama akışını saniye saniye izlemek istiyorsanız, logları “follow” modunda açabilirsiniz. Bunun için komutun sonuna -f parametresini eklemeniz yeterlidir:

Bash

kubectl logs -f mynginx

Bu modda terminaliniz kapanmaz ve yeni bir log satırı oluştuğunda anında ekranınıza düşer.

Adım 4: Detaylı Analiz ve Sorun Giderme

Log çıktılarında uygulamanın çalışma zamanı (runtime) bilgilerini, örneğin Nginx için start worker process mesajlarını veya uygulama hatalarını görebilirsiniz. Eğer bir pod içerisinde birden fazla container varsa, logları görmek için -c parametresi ile container ismini belirtmeniz gerekeceğini unutmayın.

Azure Kubernetes Service (AKS): LoadBalancer Servisi ile Uygulamaları İnternete Açma

Posted on by Posted in Genel Leave a comment

Kubernetes üzerinde deploy edilen bir pod’a dış dünyadan erişim sağlamak için Service objelerini kullanırız. Service objeleri, gelen trafiği ilgili pod’lara yönlendirmenin yanı sıra AKS cluster içerisindeki pod’ların birbirleriyle haberleşmesini sağlayan birer endpoint görevi görür. “Bir pod’a dışarıdan nasıl ulaşabilirim?” sorusunun temel cevabı servis objeleridir.

Bu makalede, Azure altyapısını kullanarak bir uygulamayı internete açmak için LoadBalancer tipinde bir servis objesinin nasıl oluşturulacağını adım adım inceleyeceğiz.

LoadBalancer Servis Manifestosu Hazırlama

Uygulamamızı internete açmak istediğimizde LoadBalancer tipi en yaygın tercihlerden biridir. Bu servis tipi kullanıldığında, bulut sağlayıcısı (Microsoft Azure) servis için otomatik olarak bir public IP adresi atar.

Aşağıdaki yapılandırmayı içeren bir aspnetapp-service.yaml dosyası oluşturun:

YAML

apiVersion: v1
kind: Service
metadata:
  name: aspnetapp-service
spec:
  type: LoadBalancer
  selector:
    app: aspnetapp
  ports:
    - port: 80          # Dışarıya açılan port
      targetPort: 8080  # Pod içindeki container portu
      protocol: TCP

Kritik Detay: Selector Kullanımı Manifesto içerisindeki selector kısmı büyük önem taşır. Buraya, ağ trafiğini yönlendirmek istediğiniz pod’un etiket ismini (label) girmeniz gerekir. Bu sayede dışarıdan gelen trafik, ilgili pod’a doğru bir şekilde yönlendirilir.

Servisin Dağıtımı (Deployment)

Hazırladığımız servis manifestosunu AKS cluster’ına uygulamak için terminal üzerinden kubectl komutunu çalıştırıyoruz:

Bash

kubectl apply -f aspnetapp-service.yaml

[RESİM 1: kubectl apply -f aspnetapp-service.yaml komut çıktısı]

Komut çalıştırıldıktan sonra service/aspnetapp-service created mesajı ile objenin başarıyla oluşturulduğu teyit edilir.

Azure Üzerinde Public IP Ataması ve Doğrulama

LoadBalancer tipinde bir servis oluşturulduğunda, Azure altyapısı bu servis için bir adet Public IP tahsis eder. Bu işlem, bulut sağlayıcısının arka planda Load Balancer kaynağını yapılandırması nedeniyle kısa bir süre alabilir.

Servis durumunu ve atanan IP adresini Azure Portal’da “Services and ingresses” sekmesinden veya CLI üzerinden kontrol edebilirsiniz.

[RESİM 2: Azure Portal – Services and Ingresses ekranı ve External IP görünümü]

Örnek yapılandırmamızda Azure tarafından servisimize 4.182.176.54 şeklinde bir dış IP (External IP) atanmıştır.

Uygulamaya İnternetten Erişim

Atanan bu IP adresini tarayıcınıza yazarak uygulamanızın internet üzerinden ulaşılabilir olup olmadığını test edebilirsiniz.

[RESİM 3: Tarayıcı üzerinden IP adresi ile erişilen uygulama ekranı]

Görüldüğü üzere, servis objesi sayesinde AKS üzerinde çalışan uygulamamız başarılı bir şekilde dış dünyaya açılmıştır. Bir sonraki aşamada uygulamamızı daha yönetilebilir hale getirmek için farklı Kubernetes objelerini inceleyeceğiz.

Microsoft Azure AKS’de ImagePullBackOff Hatası Nedir ve Nasıl Çözülür?

Posted on by Posted in Genel Leave a comment

Azure Kubernetes Service (AKS) üzerinde uygulamalarınızı deploy ederken karşılaşabileceğiniz en yaygın hatalardan biri ImagePullBackOff hatasıdır. Bu hata, temel olarak Kubernetes’in belirlediğiniz container imajını (image) çeşitli nedenlerle indiremediğini (pull edemediğini) gösterir.

AKS ortamında bu hatanın temel olarak iki ana sebebi vardır:

  1. İmaj isminin veya etiketinin (tag) yanlış yazılması.
  2. Azure Container Registry (ACR) veya dış bir registry’den imajı çekmek için gerekli yetkilerin (credentials) eksik olması.

Bu makalede, kasıtlı olarak hatalı bir imaj ismi girerek Azure AKS üzerinde bu hatayı nasıl simüle edeceğimizi ve komut satırı üzerinden (CLI) sorunun kaynağını nasıl tespit edeceğimizi adım adım inceleyeceğiz.

Sorunsuz Bir Pod YAML Örneği

Normal şartlarda, doğru bir Microsoft imajı kullanarak hazırladığımız bir Pod manifestosu aşağıdaki gibidir ve deploy edildiğinde sorunsuz çalışır:

YAML

apiVersion: v1
kind: Pod
metadata:
  name: aspnetapp
  labels:
    app: aspnetapp
spec:
  containers:
  - image: "mcr.microsoft.com/dotnet/samples:aspnetapp"
    name: aspnetapp-image
    ports:
    - containerPort: 8080
      protocol: TCP

Adım 1: Hatayı Simüle Etmek İçin YAML’ı Düzenleme

Şimdi, hatanın nasıl göründüğünü ve nasıl çözüleceğini anlamak için image ismini bilerek hatalı (repolarında bulunmayan bir isimle) değiştirelim. İmajın sonuna xyz ekliyoruz:

YAML

apiVersion: v1
kind: Pod
metadata:
  name: aspnetap-imagepullbackof
  labels:
    app: aspnetapp
spec:
  containers:
  - image: "mcr.microsoft.com/dotnet/samples:aspnetappxyz" # Kasıtlı olarak yanlış yazılmış imaj ismi
    name: aspnetapp-image
    ports:
    - containerPort: 8080
      protocol: TCP

Hazırladığımız bu hatalı YAML dosyasını AKS cluster’ımıza deploy ediyoruz:

Bash

kubectl apply -f aspnetapp.yaml

[RESİM 1: kubectl apply komut çıktısı]

Adım 2: Azure Portal ve CLI Üzerinden Hatayı Tespit Etme

Manifestomuz AKS’ye iletildi (created), ancak uygulamamız ayağa kalkmayacak. Durumu kontrol etmek için önce Azure Portal’a, ardından komut satırına bakalım.

Azure Portal’da Kubernetes kaynakları (Workloads -> Pods) sekmesine girdiğimizde, Ready kısmında bir uyarı olduğunu görebiliriz.

[RESİM 2: Azure Portal – ErrImagePull hatası]

Aynı durumu yerel terminalimizden kontrol etmek için aşağıdaki komutu çalıştırıyoruz:

Bash

kubectl get pods

[RESİM 3: CLI – ImagePullBackOff hatası görünümü]

Çıktıda açıkça ImagePullBackOff durumunu görüyoruz. Kubernetes, ErrImagePull ile imajı çekmeyi denedi, başaramadı ve bekleme süresini artırarak (BackOff) denemeye devam ediyor.

Adım 3: Pod Loglarını ve Event’leri İnceleme (Troubleshooting)

Sorunun tam olarak neden kaynaklandığını anlamak (isim hatası mı, yetki hatası mı?) için Pod’un detaylarına inmemiz gerekiyor. Bunun için describe komutunu kullanacağız.

Aşağıdaki komutu çalıştırarak AKS’nin bu pod ile ilgili oluşturduğu “Events” (Olaylar) loglarını detaylıca inceleyelim:

Bash

kubectl describe pod aspnetap-imagepullbackof

[RESİM 4: kubectl describe pod Events çıktısı]

Çıktının en altındaki Events bölümünü incelediğimizde sorunun kaynağını net bir şekilde görebiliyoruz:

Failed to pull image "[mcr.microsoft.com/dotnet/samples:aspnetappxyz](https://mcr.microsoft.com/dotnet/samples:aspnetappxyz)": rpc error: code = NotFound desc = failed to pull and unpack image ... not found

Sonuç: Azure AKS bize açıkça belirttiğimiz repoda aspnetappxyz adında bir imaj bulamadığını (Not Found) söylüyor.

Çözüm

Bu senaryoda çözüm oldukça basittir: YAML dosyasındaki image satırını tekrar geçerli bir imaj (örneğin [mcr.microsoft.com/dotnet/samples:aspnetapp](https://mcr.microsoft.com/dotnet/samples:aspnetapp)) ile değiştirmek ve kubectl apply -f komutunu tekrar çalıştırmaktır.

Eğer imaj isminden eminseniz ancak hala bu hatayı alıyorsanız, sorunun kaynağı AKS’nin özel container registry’nize (örneğin Azure Container Registry – ACR) erişim yetkisinin olmamasıdır. Bu durumda rol atamalarını (Role Assignments) kontrol etmeniz gerekecektir.