Home Lab: Kubernetes DNS ve SSL Yönetimi

Ev laboratuvarınızda Kubernetes projelerinizi güvenli ve erişilebilir kılmak ister misiniz? Bu rehber, Kubernetes DNS ve SSL sertifika yönetiminin inceliklerini sıfırdan öğrenmenizi, uygulamalı örneklerle kendi ortamınızda güvenli ve istikrarlı bir altyapı oluşturmanızı sağlayacak. İç ağınızda sorunsuz hizmet keşfi ve dış dünyaya açılan uygulamalarınız için otomatik SSL yapılandırması ile projelerinizi bir üst seviyeye taşıyın.

Modern uygulama geliştirmenin ve dağıtımının temel taşlarından biri olan Kubernetes, esnekliği ve ölçeklenebilirliğiyle ev laboratuvarları için de vazgeçilmez bir araç haline gelmiştir. Ancak, bu güçlü platformun tüm potansiyelini kullanabilmek için ağ ve güvenlik temellerini doğru bir şekilde anlamak ve yapılandırmak hayati öneme sahiptir. Özellikle DNS (Domain Name System) ve SSL/TLS (Secure Sockets Layer/Transport Layer Security) sertifikaları, uygulamalarınızın hem kendi içlerinde sorunsuz iletişim kurabilmesi hem de dış dünyaya güvenli bir şekilde sunulabilmesi için olmazsa olmazdır. Ev laboratuvarı ortamında bile olsa, bu konularda yapılan doğru yapılandırmalar, geliştirme süreçlerinizi hızlandırır, hata ayıklama süresini azaltır ve en önemlisi, uygulamalarınızın güvenliğini artırır.

Peki, ev laboratuvarında bu konular neden bu kadar kritik? Düşünün ki bir mikro hizmet mimarisi kurdunuz. Her bir hizmetin birbiriyle konuşması gerekiyor. Bu durumda, bir hizmetin diğerini bulabilmesi için bir tür “rehber”e ihtiyacınız var. İşte Kubernetes’in dahili DNS servisi (CoreDNS) bu rehber rolünü üstlenerek hizmet keşfini otomatize eder. Uygulamalarınızın isimleriyle birbirlerini bulabilmesi, IP adreslerini ezberleme veya manuel konfigürasyon yapma zorunluluğunu ortadan kaldırır. Bu, geliştiriciler için büyük bir kolaylık sağlarken, aynı zamanda uygulamanın daha dinamik ve esnek olmasını sağlar. Bir hizmetin IP adresi değişse bile, diğer hizmetler onu ismiyle bulmaya devam edebilir.

Öte yandan, dış dünyaya açtığınız web uygulamalarınız için güvenlik, asla göz ardı edilmemesi gereken bir konudur. Bir web uygulamasının kullanıcı verilerini güvenli bir şekilde iletmesi, tarayıcı ile sunucu arasındaki iletişimin şifrelenmesiyle mümkündür. İşte burada SSL/TLS sertifikaları devreye girer. Bir ev laboratuvarında bile olsa, kişisel projelerinizi veya denemelerinizi yayınlarken, kullanıcıların tarayıcılarında “güvenli bağlantı” simgesini görmeleri, hem sizin projenize olan güveni artırır hem de veri bütünlüğünü sağlar. Manuel sertifika oluşturma ve yönetme süreçleri zaman alıcı ve hataya açık olabilirken, Kubernetes’teki araçlar (örneğin Cert-Manager) bu süreci tamamen otomatikleştirebilir. Bu, özellikle sürekli değişen veya kısa ömürlü test ortamlarında büyük bir avantajdır. Kısacası, Kubernetes ev laboratuvarınızda ağ ve güvenliğin temellerini sağlam atmak, hem verimliliğinizi artıracak hem de projelerinizin gelecekteki ölçeklenebilirliği ve güvenliği için sağlam bir zemin hazırlayacaktır.

Kubernetes’te DNS (Hizmet Keşfi) Nasıl Çalışır ve Neden CoreDNS Kullanıyoruz?

Kubernetes ortamında uygulamaların birbirini bulabilmesi, yani “hizmet keşfi”, modern dağıtık sistemlerin en temel gereksinimlerinden biridir. Bu keşif mekanizması, genellikle DNS (Domain Name System) üzerinden sağlanır. Kubernetes, ClusterIP, NodePort, LoadBalancer gibi çeşitli servis tipleriyle uygulamalarınızı dış dünyaya açarken, bu servislerin ve dolayısıyla arkasındaki Pod’ların birbirleriyle ve diğer servislerle isim üzerinden iletişim kurabilmesini sağlar. Geleneksel olarak, her Pod veya servis, dinamik olarak atanan bir IP adresine sahiptir ve bu IP adresleri değişebilir. IP adreslerine doğrudan bağımlı olmak, uygulamaların esnekliğini ve dayanıklılığını ciddi şekilde kısıtlar. İşte bu noktada Kubernetes’in DNS servisi devreye girerek bu bağımlılığı ortadan kaldırır.

Kubernetes’in geçmiş sürümlerinde kube-dns kullanılırken, günümüzde standart olarak CoreDNS tercih edilmektedir. CoreDNS, esnekliği, performansı ve eklenti tabanlı mimarisi sayesinde Kubernetes ortamlarında hizmet keşfi için ideal bir çözümdür. CoreDNS, bir Kubernetes kümesi içinde kube-system namespace’inde bir Pod olarak çalışır ve tüm Pod’lara varsayılan DNS sunucusu olarak tanıtılır. Bir Pod, başka bir servise erişmek istediğinde, DNS sorgusu yapar ve CoreDNS bu sorguya ilgili servisin ClusterIP’si ile yanıt verir. Bu sayede, uygulamalar IP adresi yerine anlamlı isimlerle birbirleriyle iletişim kurabilirler.

CoreDNS’in sağladığı hizmet keşfi mekanizması, basitçe servis isimlerini IP adreslerine dönüştürmekle kalmaz, aynı zamanda farklı namespace’lerdeki servisler için de tam nitelikli alan adları (FQDN – Fully Qualified Domain Name) sağlar. Örneğin, my-service.my-namespace.svc.cluster.local gibi bir isimle başka bir namespace’deki bir servise erişebilirsiniz. svc.cluster.local kısmı, kümenin varsayılan DNS sonekidir. Kendi ev laboratuvarınızda birden fazla uygulama veya mikro hizmet çalıştırmak istediğinizde, CoreDNS’in sağladığı bu kolaylık, ağ yapılandırmasıyla uğraşmak yerine uygulama geliştirme ve dağıtımına odaklanmanızı sağlar.

Şimdi bir örnekle bu durumu pekiştirelim. Diyelim ki bir web uygulamanız (frontend-app) ve bu uygulamanın kullandığı bir veritabanı (backend-db) servisiniz var. Her iki servis de farklı Pod’larda çalışıyor olabilir. frontend-app‘in backend-db‘ye erişmesi için IP adresini bilmesine gerek yoktur; sadece ismini bilmesi yeterlidir:

apiVersion: v1
kind: Service
metadata:
  name: backend-db
  labels:
    app: backend-db
spec:
  selector:
    app: backend-db
  ports:
    - protocol: TCP
      port: 5432
      targetPort: 5432
  type: ClusterIP

Bu Service tanımını uyguladığınızda, Kubernetes kümeniz içinde backend-db.default.svc.cluster.local (varsayılan namespace'deyseniz backend-db de yeterlidir) adında bir DNS kaydı oluşur. frontend-app Pod'unuz, backend-db DNS adını çözümleyerek veritabanı servisine kolayca ulaşabilir. Bu, Kubernetes'in içindeki hizmet keşfinin ne kadar basit ve etkili olduğunu gösterir. Ev laboratuvarınızda karmaşık ağ yapılandırmaları yerine, uygulama geliştirmenize ve test etmenize odaklanmanızı sağlar. CoreDNS'in esnek yapısı sayesinde, DNS çözümü için özel gereksinimleriniz olduğunda bile kolayca yapılandırma yapabilirsiniz.

Ev Laboratuvarında Kubernetes Uygulamaları İçin SSL/TLS Sertifikalarını Nasıl Yönetebiliriz?

İnternet üzerindeki her türlü iletişimde güvenlik, artık bir lüks değil, bir zorunluluktur. Ev laboratuvarınızda bile olsa, dış dünyaya açtığınız web uygulamalarınızın HTTPS protokolü üzerinden güvenli bir bağlantı sunması hem veri bütünlüğünü korur hem de kullanıcılarınıza güven verir. Kubernetes ortamında SSL/TLS sertifikalarını yönetmek, başlangıçta karmaşık görünebilir ancak doğru araçlarla bu süreç tamamen otomatize edilebilir. Bu bölümde, Kubernetes uygulamalarınız için SSL/TLS sertifikalarını nasıl sağlayacağımızı ve yöneteceğimizi adım adım inceleyeceğiz.

Kubernetes'te SSL/TLS sertifikalarını genellikle iki ana bileşen kullanarak yönetiriz: Bir Ingress Controller ve bir sertifika yönetim aracı olan Cert-Manager. Ingress Controller (örneğin Nginx Ingress Controller), dışarıdan gelen HTTP/HTTPS trafiğini Kubernetes içindeki servislere yönlendiren bir katmandır. SSL/TLS sonlandırmasını (termination) genellikle Ingress Controller yapar, yani şifreli trafiği çözer ve şifresiz olarak arka uç servislerine iletir. Cert-Manager ise bu Ingress Controller'ın kullanacağı SSL/TLS sertifikalarını otomatik olarak sağlayıp yenileyen güçlü bir araçtır. Genellikle Let's Encrypt gibi ücretsiz bir Sertifika Yetkilisi (CA) ile entegre çalışarak sertifika alma ve yenileme süreçlerini basitleştirir.

Ev laboratuvarınızda bir web uygulamasını yayınlarken SSL/TLS sertifikası sağlamanın adımları genellikle şu şekildedir:

1. Bir Alan Adı (Domain Name) Edinin: Let's Encrypt gibi CA'lar genellikle gerçek bir alan adına sertifika verir. Dinamik DNS (DDNS) hizmetleri (örn. DuckDNS, No-IP) veya kendi özel alan adınızı kullanabilirsiniz.
2. Ingress Controller Kurulumu: Nginx Ingress Controller gibi popüler bir çözümü kümenize kurun. Bu, dışarıdan gelen trafiği yönetmek için bir giriş noktası sağlayacaktır.
3. Cert-Manager Kurulumu: Cert-Manager'ı kümenize Helm veya YAML dosyaları aracılığıyla kurun.
4. Issuer veya ClusterIssuer Tanımlaması: Cert-Manager'a hangi Sertifika Yetkilisi'nden (örneğin Let's Encrypt) sertifika alacağını ve hangi kimlik doğrulama yöntemini (HTTP01 veya DNS01 challenge) kullanacağını bildirin. Ev laboratuvarları için genellikle HTTP01 challenge (Ingress üzerinden) veya DNS01 challenge (DDNS sağlayıcınızın API'si aracılığıyla) tercih edilir.
5. Uygulamanız İçin Ingress Kaydı Oluşturma: Uygulamanızın servis ve alan adı bilgilerini içeren bir Ingress kaynağı tanımlayın. Bu Ingress kaynağına Cert-Manager'ın kullanacağı Issuer/ClusterIssuer'ı belirten anotasyonları ekleyerek sertifikanın otomatik olarak sağlanmasını tetikleyin.

Bu adımların tamamlanmasıyla birlikte, Cert-Manager otomatik olarak Let's Encrypt ile iletişime geçecek, alan adınız için bir sertifika talebinde bulunacak, alan adı sahipliğini doğrulayacak ve sertifikayı alıp Kubernetes Secret olarak saklayacaktır. Ingress Controller da bu Secret'ı kullanarak HTTPS trafiğini sonlandıracaktır. Bu süreç tamamen otomatiktir ve sertifikalarınızın süresi dolmadan önce otomatik olarak yenilenir.

Şimdi bir örnek Ingress kaynağına bakalım. Bu örnekte, my-app.example.com alan adı için Cert-Manager tarafından otomatik olarak bir SSL/TLS sertifikası sağlanacak ve bu sertifika kullanılarak my-app-service adlı servise trafik yönlendirilecektir:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app-ingress
  annotations:
    kubernetes.io/ingress.class: "nginx"
    cert-manager.io/cluster-issuer: "letsencrypt-prod" # ClusterIssuer adınız
spec:
  tls:
  - hosts:
    - my-app.example.com
    secretName: my-app-tls # Sertifikanın saklanacağı Secret adı
  rules:
  - host: my-app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-app-service
            port:
              number: 80

Bu YAML dosyası, Cert-Manager'ın letsencrypt-prod adlı ClusterIssuer'ı kullanarak my-app.example.com için bir sertifika almasını ve bunu my-app-tls adlı bir Secret'a kaydetmesini sağlar. Ingress Controller, bu Secret'ı kullanarak gelen HTTPS trafiğini sonlandırır. Bu yapılandırma ile, ev laboratuvarınızdaki uygulamalarınıza güvenli ve şifreli erişim sağlamak için önemli bir adımı atmış olursunuz. Unutmayın, bu kurulumu yaparken kullandığınız alan adının doğru bir şekilde DNS çözümü yapması ve Kubernetes Ingress Controller'ınızın dışarıdan erişilebilir olması gerekmektedir.

Gerçek Dünya Senaryosu: Ev Laboratuvarında Uçtan Uca DNS ve SSL Kurulumu

Şimdiye kadar Kubernetes'te DNS ve SSL'in temel kavramlarını ve bileşenlerini ayrı ayrı ele aldık. Ancak, bu teknolojileri ev laboratuvarınızda bir araya getirerek gerçek bir uygulama için nasıl uçtan uca bir çözüm oluşturabiliriz? Bu bölümde, popüler bir içerik yönetim sistemi olan WordPress'i ev laboratuvarı Kubernetes kümemize dağıtarak, özel bir alan adı üzerinden erişilebilir hale getireceğiz ve tam otomatik SSL/TLS sertifikası sağlayacağız. Bu vaka analizi, teorik bilgileri pratik bir senaryoya dönüştürmenize yardımcı olacaktır.

Senaryo: WordPress Uygulamasını Özel Alan Adı ve HTTPS ile Yayınlama

Hedefimiz: Bir WordPress uygulamasını wordpress.homelab.com gibi kendi seçtiğimiz bir alan adı üzerinden yayınlamak ve bu alan adına Let's Encrypt tarafından sağlanan otomatik SSL sertifikası ile güvenli HTTPS erişimi sağlamak. Bu, ev ağımız dışından bile erişilebilir olacak.

1. Adım: Ön Koşullar ve Temel Kurulumlar

• Kubernetes Kümesi: Çalışan bir Kubernetes kümeniz olmalı (örn. K3s, Minikube).
• Ingress Controller: Nginx Ingress Controller kurulmuş olmalı. (Kurulum için Nginx Ingress dokümanlarına bakabilirsiniz.)
• Cert-Manager: Cert-Manager kurulmuş ve bir ClusterIssuer (örneğin letsencrypt-prod veya letsencrypt-stag) tanımlanmış olmalı.
• Alan Adı ve DNS Ayarları: wordpress.homelab.com gibi bir alan adınız olmalı ve bu alan adının DNS kaydı (A kaydı), ev ağınızın dış IP adresini işaret etmeli. Ev ağınızda port yönlendirme (port forwarding) yaparak 80 ve 443 numaralı portları Kubernetes Ingress Controller'ınızın çalıştığı sunucuya yönlendirmelisiniz. Eğer statik bir IP'niz yoksa, Dinamik DNS (DDNS) servislerini kullanabilirsiniz.

2. Adım: WordPress ve MySQL Dağıtımı

WordPress için bir MySQL veritabanına ihtiyacımız var. Kalıcı depolama için PersistentVolume ve PersistentVolumeClaim kullanacağız.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-pv-claim
  labels:
    app: wordpress
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: wordpress-mysql
  labels:
    app: wordpress
spec:
  selector:
    matchLabels:
      app: wordpress
      tier: mysql
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: wordpress
        tier: mysql
    spec:
      containers:
      - image: mysql:5.7
        name: mysql
        env:
        - name: MYSQL_ROOT_PASSWORD
          value: YOUR_ROOT_PASSWORD # Güçlü bir şifre belirleyin
        - name: MYSQL_DATABASE
          value: wordpress
        - name: MYSQL_USER
          value: wordpress
        - name: MYSQL_PASSWORD
          value: YOUR_WORDPRESS_PASSWORD # Güçlü bir şifre belirleyin
        ports:
        - containerPort: 3306
          name: mysql
        volumeMounts:
        - name: mysql-persistent-storage
          mountPath: /var/lib/mysql
      volumes:
      - name: mysql-persistent-storage
        persistentVolumeClaim:
          claimName: mysql-pv-claim
---
apiVersion: v1
kind: Service
metadata:
  name: wordpress-mysql
  labels:
    app: wordpress
spec:
  ports:
    - port: 3306
  selector:
    app: wordpress
    tier: mysql
  clusterIP: None # Headless servis olarak ayarla

Yukarıdaki YAML dosyasını uygulayarak MySQL veritabanını ve ona bağlı servisi dağıtın. YOUR_ROOT_PASSWORD ve YOUR_WORDPRESS_PASSWORD alanlarını kendi güçlü şifrelerinizle değiştirin.

3. Adım: WordPress Uygulamasının Dağıtımı

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: wp-pv-claim
  labels:
    app: wordpress
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: wordpress
  labels:
    app: wordpress
spec:
  selector:
    matchLabels:
      app: wordpress
      tier: frontend
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: wordpress
        tier: frontend
    spec:
      containers:
      - image: wordpress:latest
        name: wordpress
        env:
        - name: WORDPRESS_DB_HOST
          value: wordpress-mysql
        - name: WORDPRESS_DB_USER
          value: wordpress
        - name: WORDPRESS_DB_PASSWORD
          value: YOUR_WORDPRESS_PASSWORD # MySQL şifresiyle aynı olmalı
        - name: WORDPRESS_DB_NAME
          value: wordpress
        ports:
        - containerPort: 80
          name: wordpress
        volumeMounts:
        - name: wordpress-persistent-storage
          mountPath: /var/www/html
      volumes:
      - name: wordpress-persistent-storage
        persistentVolumeClaim:
          claimName: wp-pv-claim
---
apiVersion: v1
kind: Service
metadata:
  name: wordpress
  labels:
    app: wordpress
spec:
  ports:
    - port: 80
  selector:
    app: wordpress
    tier: frontend
  type: ClusterIP

Bu YAML dosyasını uygulayarak WordPress uygulamasını ve ClusterIP servisini dağıtın. WORDPRESS_DB_PASSWORD değerinin MySQL şifrenizle eşleştiğinden emin olun.

4. Adım: Ingress ve Cert-Manager ile SSL Yapılandırması

Şimdi sıra, wordpress.homelab.com alan adımızı WordPress servisine yönlendirmeye ve otomatik SSL sağlamaya geldi.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: wordpress-ingress
  annotations:
    kubernetes.io/ingress.class: "nginx"
    cert-manager.io/cluster-issuer: "letsencrypt-prod" # Daha önce tanımladığınız ClusterIssuer adı
    nginx.ingress.kubernetes.io/force-ssl-redirect: "true" # Tüm HTTP trafiğini HTTPS'e yönlendir
spec:
  tls:
  - hosts:
    - wordpress.homelab.com
    secretName: wordpress-tls-secret # Sertifikanın saklanacağı Secret
  rules:
  - host: wordpress.homelab.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: wordpress
            port:
              number: 80

Bu Ingress kaynağını uyguladığınızda, Cert-Manager otomatik olarak wordpress.homelab.com için Let's Encrypt'ten bir sertifika talep edecek. Talep başarılı olursa, sertifika wordpress-tls-secret adlı bir Kubernetes Secret olarak saklanacak ve Nginx Ingress Controller bu sertifikayı kullanarak HTTPS trafiğini sonlandıracaktır. Ayrıca, nginx.ingress.kubernetes.io/force-ssl-redirect: "true" anotasyonu sayesinde tüm HTTP istekleri otomatik olarak HTTPS'e yönlendirilecektir.

Sonuç

Bu adımları tamamladıktan sonra, tarayıcınızdan https://wordpress.homelab.com adresine gittiğinizde, WordPress kurulum sihirbazını HTTPS üzerinden güvenli bir şekilde görmelisiniz. Bu senaryo, ev laboratuvarınızda bir uygulamanın hem dahili hizmet keşfi (WordPress'in MySQL'i bulması) hem de dış dünyaya güvenli bir şekilde açılması (HTTPS ile) için DNS ve SSL/TLS'in nasıl entegre edildiğini göstermektedir. Bu vaka analizi, kendi projelerinizde benzer yapılandırmaları uygulamanız için size sağlam bir temel sunar.

İleri Düzey İpuçları ve Optimizasyonlar: Ev Laboratuvarınızı Güçlendirin

Kubernetes'te DNS ve SSL/TLS'in temel kurulumlarını anladıktan sonra, ev laboratuvarınızı daha da optimize etmek ve karmaşık senaryolara hazırlamak için bazı ileri düzey ipuçları ve püf noktaları bulunmaktadır. Bu bölümde, performans, güvenlik ve yönetim kolaylığı açısından kümenizi nasıl geliştirebileceğinizi inceleyeceğiz.

Özel CoreDNS Yapılandırmaları ve DNS Politikaları

CoreDNS, esnek bir eklenti mimarisine sahiptir ve Corefile adı verilen bir ConfigMap üzerinden yapılandırılır. Ev laboratuvarınızda, varsayılan CoreDNS yapılandırmasının ötesine geçmeniz gerekebilir:

• Harici DNS Sunucuları İçin Forwarding: Kendi iç ağınızda ad.homelab.local gibi özel bir alan adınız varsa, CoreDNS'i bu alan adının sorgularını belirli bir iç DNS sunucusuna (örneğin bir dnsmasq sunucusu veya pfSense üzerindeki DNS Resolver) iletecek şekilde yapılandırabilirsiniz. Bu sayede, Kubernetes içindeki Pod'lar, dış DNS sunucusunu doğrudan bilmeden bu kaynaklara erişebilir.
• Özel DNS Kayıtları (Host Eklentisi): Belirli servisler veya harici IP adresleri için manuel DNS kayıtları eklemeniz gerekebilir. CoreDNS'in hosts eklentisi ile bu tür statik eşlemeleri kolayca yapabilirsiniz.
• Pod DNS Politikaları: Her Pod'un DNS çözümü, Pod tanımında dnsPolicy alanı ile kontrol edilebilir. ClusterFirst (varsayılan) CoreDNS'i kullanırken, Default Pod'un çalıştığı düğümün DNS yapılandırmasını kullanır. None ise tamamen özel bir DNS yapılandırmasına izin verir (dnsConfig alanı ile birlikte). Örneğin, belirli bir Pod'un sadece dış bir DNS sunucusunu kullanmasını istiyorsanız dnsPolicy: None ve dnsConfig kullanarak bu Pod'un DNS sunucularını ve arama alanlarını özelleştirebilirsiniz.

apiVersion: v1
kind: Pod
metadata:
  name: my-custom-dns-pod
spec:
  containers:
    - name: busybox
      image: busybox
      command: ["sh", "-c", "echo 'Hello from custom DNS pod!' && sleep 3600"]
  dnsPolicy: None # Varsayılan DNS politikasını devre dışı bırak
  dnsConfig:
    nameservers: # Özel DNS sunucuları
      - 8.8.8.8
      - 8.8.4.4
    searches: # Özel arama alanları
      - mydomain.com
      - example.com
    options:
      - name: ndots
        value: "2"

Wildcard Sertifikalar ve Özel CA'lar

• Wildcard Sertifikalar: Ev laboratuvarınızda birçok alt alan adı (örn. app1.homelab.com, app2.homelab.com) kullanıyorsanız, her biri için ayrı ayrı sertifika almak yerine *.homelab.com için tek bir wildcard sertifika alabilirsiniz. Bu, yönetim yükünü önemli ölçüde azaltır. Let's Encrypt wildcard sertifikaları için DNS01 challenge yöntemini gerektirir, yani Cert-Manager'ın DNS sağlayıcınızın API'si ile etkileşime geçebilmesi gerekir.
• Özel Sertifika Yetkilileri (CA'lar): Sadece iç ağınızdaki uygulamalar için sertifika sağlıyorsanız ve bu uygulamalara dışarıdan erişim olmayacaksa, kendi özel CA'nızı kurabilirsiniz. Bu CA ile imzaladığınız sertifikalar, internetteki genel CA'lardan bağımsız olarak çalışır. Güvenilirliği sağlamak için, bu özel CA'nın kök sertifikasını tüm istemci cihazlarınıza (bilgisayarlar, telefonlar) manuel olarak güvenilir olarak eklemeniz gerekir. Bu, ev laboratuvarınızda hassas servisler için ek bir güvenlik ve kontrol katmanı sağlar.

Mobil Uyumlu HTML ve Responsive Tasarım

Modern web uygulamalarının vazgeçilmez bir parçası olan mobil uyumluluk, ev laboratuvarınızda geliştirdiğiniz projeler için de geçerlidir. Kubernetes'in kendisi HTML üretmez ancak dağıttığınız uygulamalar mobil uyumlu olmalıdır. İşte küçük bir CSS media query örneği, web uygulamanızın farklı ekran boyutlarına nasıl adapte olabileceğini gösterir:

Bu CSS kodunu, uygulamanızın HTML etiketine veya harici bir .css dosyasına dahil ederek mobil uyumluluğu artırabilirsiniz. max-width değeri, stilin uygulanacağı maksimum ekran genişliğini belirtir. Bu sayede, küçük ekranlarda daha okunaklı ve kullanılabilir bir deneyim sunabilirsiniz.

Sorun Giderme ve İzleme

• DNS Sorunları: Pod'lar arası iletişimde veya dış kaynaklara erişimde sorun yaşıyorsanız, Pod'unuzun içinden nslookup veya dig komutlarını kullanarak DNS çözümlemesini test edin. kubectl exec -it -- nslookup komutu ile CoreDNS'in nasıl yanıt verdiğini görebilirsiniz. CoreDNS Pod'larının loglarını kontrol etmek (kubectl logs -f -n kube-system ), sorunun kaynağını anlamak için çok önemlidir.
• SSL Sorunları: Sertifika alamıyorsanız veya HTTPS erişimi çalışmıyorsa:
  • Cert-Manager Certificate ve CertificateRequest kaynaklarının durumunu kontrol edin (kubectl describe certificate ).
  • Cert-Manager Pod'larının loglarını inceleyin.
  • Ingress Controller Pod'larının loglarını kontrol edin.
  • Alan adınızın DNS kayıtlarının doğru olduğundan ve dışarıdan erişilebilir olduğundan emin olun (örneğin dig +short A wordpress.homelab.com).
  • Güvenlik duvarı ve port yönlendirme ayarlarınızı tekrar kontrol edin.

Bu ileri düzey ipuçları ve optimizasyonlar, ev laboratuvarı Kubernetes ortamınızı daha sağlam, güvenli ve yönetilebilir hale getirecektir. Her bir konuyu derinlemesine araştırmak, kendi özel ihtiyaçlarınıza göre en iyi çözümü bulmanıza yardımcı olacaktır.

Sonuç: Ev Laboratuvarınızda Güvenli ve Erişilebilir Uygulamalar

Bu kapsamlı makale boyunca, ev laboratuvarı ortamında Kubernetes DNS ve SSL/TLS yönetiminin temelinden ileri düzeyine kadar birçok konuyu ele aldık. Kubernetes'in dahili DNS servisi olan CoreDNS'in hizmet keşfi için ne kadar kritik olduğunu, uygulamaların isimlerle birbirini nasıl bulduğunu ve bu sayede ağ karmaşıklığının nasıl azaldığını detaylıca inceledik. Ardından, Ingress Controller ve Cert-Manager gibi araçlarla SSL/TLS sertifikalarını otomatik olarak sağlayarak uygulamalarımızı nasıl güvenli hale getirebileceğimizi öğrendik. WordPress örneği üzerinden gerçek dünya senaryosunda bu iki teknolojiyi bir araya getirerek uçtan uca bir dağıtımın adımlarını gördük.

Özetle, ev laboratuvarınızda Kubernetes kullanmak, sadece uygulamaları çalıştırmakla kalmaz, aynı zamanda bu uygulamaların sağlıklı bir şekilde iletişim kurmasını ve dış dünyaya güvenli bir şekilde sunulmasını gerektirir. DNS, bu iletişimin omurgasını oluştururken, SSL/TLS ise veri alışverişinin gizliliğini ve bütünlüğünü sağlar. Bu iki temel bileşeni doğru bir şekilde yapılandırmak, hem geliştirme süreçlerinizi hızlandıracak hem de projelerinizin profesyonel bir görünüme kavuşmasını sağlayacaktır. Otomatik sertifika yönetimi sayesinde, güvenlik endişeleriyle uğraşmak yerine daha çok uygulama geliştirmeye odaklanabilirsiniz.

Unutmayın, bir ev laboratuvarı sadece test ve öğrenme ortamı değildir; aynı zamanda gerçek dünya sorunlarına çözümler üretebileceğiniz bir sandbox'tır. Bu makaledeki bilgileri kullanarak, kendi ev laboratuvarınızda sadece işlevsel değil, aynı zamanda güvenli ve ölçeklenebilir uygulamalar oluşturmak için sağlam bir temel atmış olacaksınız. Sürekli öğrenmeye ve denemeye devam edin; Kubernetes dünyası her zaman yeni keşiflere açıktır!

Sıkça Sorulan Sorular

1. Ev laboratuvarında neden gerçek bir alan adı ve Let's Encrypt kullanmalıyım? Self-signed sertifikalar yeterli olmaz mı?

Gerçek bir alan adı ve Let's Encrypt gibi bir CA'dan alınan sertifikalar, uygulamanızın tarayıcılarda güvenli olarak algılanmasını sağlar. Self-signed sertifikalar ise tarayıcılar tarafından güvenli kabul edilmez ve kullanıcılarınıza "güvenli değil" uyarıları gösterir. Ev laboratuvarınızdaki uygulamalara dışarıdan erişim planlıyorsanız veya mobil cihazlardan sorunsuz erişim istiyorsanız, gerçek bir sertifika kullanmak kullanıcı deneyimini önemli ölçüde artırır ve profesyonel bir görünüm sunar. Sadece iç ağda ve test amaçlı kullanılacaksa self-signed sertifikalar yeterli olabilir, ancak yine de tarayıcı uyarısıyla karşılaşacaksınız.

2. CoreDNS yerine farklı bir DNS çözümü kullanabilir miyim?

Evet, teorik olarak farklı bir DNS çözümü kullanmak mümkündür ancak CoreDNS, Kubernetes ile varsayılan olarak entegre çalıştığı ve hizmet keşfi için optimize edildiği için önerilen çözümdür. Kendi DNS sunucunuzu entegre etmeye çalışmak, ek yapılandırma ve uyumluluk sorunlarına yol açabilir. CoreDNS'in esnek eklenti mimarisi sayesinde çoğu özel DNS ihtiyacınızı Corefile üzerinden yapılandırabilirsiniz.

3. Cert-Manager ile sertifikalarımın süresi dolduğunda otomatik olarak yenilenecek mi?

Evet, Cert-Manager'ın en önemli özelliklerinden biri budur. Başarılı bir şekilde yapılandırıldığında, Cert-Manager Let's Encrypt sertifikalarınızın süresi dolmadan belirli bir süre önce (genellikle 30 gün kala) otomatik olarak yenileme işlemini başlatır ve sertifikayı günceller. Bu sayede manuel yenileme süreçleriyle uğraşmak zorunda kalmazsınız ve uygulamalarınızın kesintisiz olarak HTTPS üzerinden erişilebilirliğini sağlamış olursunuz.

4. Kubernetes Ingress Controller'ı kurmak zorunlu mu? LoadBalancer veya NodePort ile SSL/TLS yapamaz mıyım?

Ingress Controller kullanmak, birden fazla uygulamayı tek bir dış IP adresi veya alan adı üzerinden yayınlamak ve SSL/TLS sonlandırmasını merkezi olarak yönetmek için en etkili yoldur. LoadBalancer veya NodePort ile de SSL/TLS yapabilirsiniz, ancak bu genellikle daha fazla manuel yapılandırma gerektirir ve her servis için ayrı ayrı SSL yönetimi yapmanız gerekebilir. Ingress, özellikle Cert-Manager ile entegre olduğunda, SSL/TLS sertifika yönetimini büyük ölçüde basitleştirir ve bir uygulama ağ geçidi görevi görür.