Kubernetes’te Cert-Manager: Otomatik TLS Sertifika Yönetimi için Eksiksiz Kurulum Kılavuzu

Cert-Manager, TLS sertifikalarının yaşam döngüsünü — ilk düzenlemeden doğrulama ve yenilemeye kadar — Let’s Encrypt, HashiCorp Vault ve özel PKI sistemleri gibi sertifika yetkilileriyle doğrudan entegre olarak tam otomatik hale getiren açık kaynaklı bir Kubernetes denetleyicisidir. Sertifikaları, Özel Kaynak Tanımları (CRDs) aracılığıyla bildirimsel olarak yönetilen yerel Kubernetes kaynakları olarak ele alarak manuel sertifika iş akışlarını ortadan kaldırır.

Herhangi bir üretim Kubernetes kümesinde, süresi dolmuş veya yanlış yapılandırılmış TLS sertifikaları, planlanmamış kesintilerin en yaygın nedenlerinden biridir. Cert-Manager, sertifika durumunu sürekli olarak uzlaştırarak, kimlik bilgilerini sona ermeden önce otomatik olarak yenileyerek ve Ingress denetleyicilerinin ve iş yüklerinin hemen kullanabileceği Kubernetes Secrets’ta elde edilen anahtar materyali depolayarak bu sorunu çözer.

Cert-Manager’ın Kubernetes TLS Otomasyonunda Standart Olmasının Nedeni

Cert-Manager fiili çözüm haline gelmeden önce, ekipler ya bireysel düğümlerde certbot yenilemelerini komut dosyasıyla gerçekleştiriyor, sertifikaları ad alanları arasında manuel olarak döndürüyor ya da satıcı bağımlılığı yaratan bulut sağlayıcısına özgü entegrasyonlara güveniyordu. Cert-Manager, tüm bu yaklaşımları tek, Kubernetes-yerel bir kontrol düzlemi altında birleştirir.

Geçici yaklaşımlara göre temel avantajlar:

• Bildirimsel yönetim: Sertifika amacı, uygulama koduyla birlikte sürüm kontrollü bir YAML manifestosu olarak ifade edilir.
• Otomatik uzlaştırma: Denetleyici döngüsü, istenen ve gerçek sertifika durumu arasındaki sapmayı tespit eder ve insan müdahalesi olmadan düzeltir.
• Çoklu yayıncı desteği: Tek bir küme, genel hizmetler için Let’s Encrypt’i, servis ağı mTLS için dahili bir CA’yı ve gizlilik açısından hassas iş yükleri için HashiCorp Vault’u aynı anda kullanabilir.
• Denetim izi: Her CertificateRequest nesnesi Kubernetes API’sinde kalıcı olarak saklanır ve size eksiksiz bir düzenleme geçmişi sunar.

NVMe destekli depolama ve tam kök erişimine sahip bir VPS Hosting platformunda Kubernetes çalıştırmak, özel DNS çözümleyicileri yapılandırmak, ACME HTTP-01 zorlukları için güvenlik duvarı kurallarını yönetmek ve küme düzeyinde CRDs’yi kısıtlama olmaksızın yüklemek için gereken kontrolü size sağlar — bunların hepsi üretim kalitesinde bir Cert-Manager dağıtımı için ön koşullardır.

Temel Mimari: Cert-Manager Dahili Olarak Nasıl Çalışır

Cert-Manager’ın dahili mimarisini anlamak, yanlış yapılandırmaları önler ve düzenleme hatalarını hızlı bir şekilde ayıklamanıza yardımcı olur.

Sertifika Yaşam Döngüsü Durum Makinesi

Cert-Manager, sertifikaları deterministik bir durum makinesi aracılığıyla yönetir. Her Certificate kaynağı aşağıdaki durumlardan geçer:

1. Beklemede — Certificate nesnesi mevcut ancak geçerli bir CertificateRequest yerine getirilmemiş.
2. Düzenleniyor — Bir CertificateRequest oluşturulmuş ve yapılandırılmış yayıncıya gönderilmiş.
3. Hazır — Geçerli, süresi dolmamış bir sertifika, başvurulan Kubernetes Secret‘ında depolanmış.
4. Yenileme Beklemede — Sertifika, renewBefore penceresi içinde (varsayılan: sona ermeden 30 gün önce) ve yeni bir CertificateRequest işleniyor.

Denetleyici, küme genelindeki tüm Certificate nesnelerini izler ve durumlarını sürekli olarak uzlaştırır. Bir Secret manuel olarak silinirse, Cert-Manager eksik kaynağı tespit eder ve hemen yeniden düzenlemeyi tetikler — bu, kazara kesintileri önleyen kritik bir kendi kendini iyileştirme davranışıdır.

Temel CRD Bileşenleri

Order ve Challenge kaynakları ACME yayıncısı tarafından otomatik olarak oluşturulur — bunlarla nadiren doğrudan etkileşime girersiniz, ancak düzenleme durduğunda bunları incelemek birincil hata ayıklama yoludur.

Sertifika Depolama ve Secret Formatı

Düzenlendikten sonra Cert-Manager, hedef Kubernetes Secret‘ına üç veri anahtarı yazar:

tls.crt — PEM kodlu tam sertifika zinciri (yaprak + ara sertifikalar).
tls.key — PEM kodlu özel anahtar.
ca.crt — Düzenleyen CA sertifikası (dahili CA’lar için doldurulur; ACME yayıncıları için boş olabilir).

Ingress denetleyicileri, servis ağları ve uygulama pod’ları bu Secret‘ı doğrudan bağlar. Format, NGINX, Traefik, Istio, Linkerd ve diğer Kubernetes-yerel TLS tüketicilerinin çoğuyla uyumludur.
Desteklenen Yayıncılar ve Her Birinin Ne Zaman Kullanılacağı
ACME (Let’s Encrypt ve Alternatifleri)
ACME protokolü en yaygın düzenleme yoludur. Cert-Manager, hem hazırlık hem de üretim uç noktalarını destekleyen tam RFC 8555 ACME istemcisini uygular.
HTTP-01 zorluğu: Cert-Manager, http://<domain>/.well-known/acme-challenge/<token> adresinde geçici olarak bir token sunar. Bu, etki alanının 80 numaralı bağlantı noktasında kamuya açık erişilebilir bir IP’ye çözümlenmesini gerektirir. Tek etki alanlı ve SAN sertifikaları için çalışır ancak joker karakter sertifikaları düzenleyemez.
DNS-01 zorluğu: Cert-Manager, bir DNS sağlayıcı API’si aracılığıyla bir _acme-challenge.<domain> TXT kaydı oluşturur. Bu, güvenlik duvarlarının arkasında çalışır, joker karakter sertifikalarını (*.example.com) destekler ve doğrudan internete açık olmayan herhangi bir küme için gereklidir. Desteklenen DNS sağlayıcıları arasında Cloudflare, Route53, Google Cloud DNS, Azure DNS ve webhook çözücüler aracılığıyla diğerleri bulunmaktadır.
HashiCorp Vault
Vault yayıncısı, Vault’un PKI secrets motoru ile entegre olur. Şunlar için tercih edilen seçimdir:

Sertifikaların kısa ömürlü olması gereken (aylar değil, saatler) dahili mikro servis mTLS.
Özel anahtarların asla Vault’u terk etmemesi gereken katı anahtar gözetim gereksinimlerine sahip ortamlar.
Vault’un kira yenileme sistemine bağlı otomatik sertifika rotasyonu.

Kendinden İmzalı ve CA Yayıncıları
SelfSigned yayıncısı, sertifikanın kendi özel anahtarı tarafından imzalanmış sertifikalar oluşturur — küme içinde bir kök CA önyüklemek için kullanışlıdır. CA yayıncısı, sertifikaları imzalamak için bir CA anahtar çifti içeren bir Kubernetes Secret‘ı kullanır ve bu da onu dahili geliştirme ortamları ve servis ağı PKI için uygun kılar.
Venafi
Venafi entegrasyonu, merkezi sertifika politikası uygulaması, uyumluluk denetimi ve donanım güvenlik modülleri (HSM’ler) ile entegrasyona sahip kurumsal ortamları hedefler.
Cert-Manager ile Alternatif TLS Otomasyon Yaklaşımlarının Karşılaştırması



Yaklaşım
Joker Karakter Desteği
Kubernetes Yereli
Çoklu CA
Otomatik Yenileme
Karmaşıklık








—
—
—
—
—
—








Cert-Manager
Evet (DNS-01)
Evet (CRDs)
Evet
Evet
Orta








Manuel Certbot
Hayır (yalnızca HTTP-01)
Hayır
Sınırlı
Komut Dosyalı
Düşük–Orta








Bulut LB TLS Sonlandırma
Değişir
Hayır
Hayır
Evet
Düşük








Istio / Servis Ağı CA
Yalnızca dahili
Evet
Hayır
Evet
Yüksek








HashiCorp Vault (bağımsız)
Evet
Hayır
Evet
Manuel
Yüksek





Kubernetes’i bir Dedicated Server veya VPS üzerinde çalıştıran ekipler için Cert-Manager, aynı anda hem Kubernetes-yerel olan, hem tüm büyük CA’ları destekleyen hem de süregelen manuel müdahale gerektirmeyen tek yaklaşımdır.
Cert-Manager Kurulumu: Üretime Hazır Kurulum
Ön Koşullar

Kubernetes 1.22+ (tam CRD kararlılığı için 1.26+ önerilir)
Küme yöneticisi ayrıcalıklarıyla yapılandırılmış kubectl

Kendi etki alanınızı yönetiyorsanız, bir API sunan sağlayıcı aracılığıyla Domain Registration yapmanız şiddetle tavsiye edilir — bu, manuel müdahale olmaksızın tamamen otomatik DNS-01 zorluk çözümünü mümkün kılar.

Adım 1: CRDs ve Cert-Manager Denetleyicisini Kurun

Önerilen üretim kurulum yöntemi, Helm yükseltme çakışmalarını önlemek için CRDs’nin ayrı olarak yönetildiği Helm kullanımıdır:

# Add the Jetstack Helm repository
helm repo add jetstack https://charts.jetstack.io
helm repo update

# Install Cert-Manager with CRDs included
helm install cert-manager jetstack/cert-manager 
  --namespace cert-manager 
  --create-namespace 
  --version v1.14.5 
  --set installCRDs=true 
  --set global.leaderElection.namespace=cert-manager

Devam etmeden önce üç temel pod’un çalıştığını doğrulayın:

kubectl get pods --namespace cert-manager

Beklenen çıktı:

NAME                                       READY   STATUS    RESTARTS   AGE
cert-manager-xxxxxxxxx-xxxxx              1/1     Running   0          60s
cert-manager-cainjector-xxxxxxxxx-xxxxx   1/1     Running   0          60s
cert-manager-webhook-xxxxxxxxx-xxxxx      1/1     Running   0          60s

cainjector, CA paket verilerini webhook yapılandırmalarına enjekte eder. webhook, Cert-Manager CRD nesnelerini doğrular ve değiştirir — çalışmıyorsa, Cert-Manager kaynaklarındaki tüm kubectl apply işlemleri başarısız olur.

Adım 2: Let’s Encrypt için ClusterIssuer Yapılandırın

Üretim hız sınırlarına çarpmamak için her zaman Let’s Encrypt hazırlık ortamıyla başlayın (haftada kayıtlı etki alanı başına 50 sertifika):

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-staging
spec:
  acme:
    server: https://acme-staging-v02.api.letsencrypt.org/directory
    email: ops@example.com
    privateKeySecretRef:
      name: letsencrypt-staging-account-key
    solvers:
      - http01:
          ingress:
            class: nginx

Hazırlık sertifikaları başarıyla düzenlendiğinde, üretim yayıncısını oluşturun:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: ops@example.com
    privateKeySecretRef:
      name: letsencrypt-prod-account-key
    solvers:
      - http01:
          ingress:
            class: nginx

Her iki manifestoyu da uygulayın:

kubectl apply -f clusterissuer-staging.yaml
kubectl apply -f clusterissuer-prod.yaml

Yayıncı hazırlığını doğrulayın:

kubectl describe clusterissuer letsencrypt-prod

Status.Conditions alanı Ready: True göstermelidir. False gösteriyorsa, ACME hesap kaydı başarısız olmuştur — e-posta adresini ve cert-manager pod’undan ağ bağlantısını kontrol edin.

Adım 3: Açıkça Sertifika İsteyin

Sertifikaları doğrudan bir Certificate kaynağı oluşturarak veya bir Ingress kaynağına açıklama ekleyerek isteyebilirsiniz. Açık Certificate yaklaşımı size daha fazla kontrol sağlar:

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: example-com-tls
  namespace: production
spec:
  secretName: example-com-tls-secret
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer
  commonName: example.com
  dnsNames:
    - example.com
    - www.example.com
  duration: 2160h    # 90 days (Let's Encrypt default)
  renewBefore: 720h  # Renew 30 days before expiry

Uygulayın ve düzenlemeyi izleyin:

kubectl apply -f certificate.yaml
kubectl describe certificate example-com-tls -n production

Ayrıntılı durum için CertificateRequest ve Order nesnelerini izleyin:

kubectl get certificaterequest -n production
kubectl describe order -n production

Adım 4: Ingress Açıklama Yöntemi (Basitleştirilmiş)

NGINX Ingress Controller kullanan ekipler için Cert-Manager, bir açıklama aracılığıyla otomatik olarak tetiklenebilir — ayrı bir Certificate manifestosuna gerek yoktur:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
  namespace: production
  annotations:
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - example.com
        - www.example.com
      secretName: example-com-tls-secret
  rules:
    - host: example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: example-service
                port:
                  number: 80

Cert-Manager açıklamayı algılar ve otomatik olarak ilgili Certificate kaynağını oluşturur. Bu, GitOps iş akışlarında en yaygın kullanılan kalıptır.

Gelişmiş Yapılandırma Kalıpları

DNS-01 ile Joker Karakter Sertifikaları (Cloudflare Örneği)

Joker karakter sertifikaları DNS-01 doğrulaması gerektirir. Önce Cloudflare API token’ınızı içeren bir Secret oluşturun:

kubectl create secret generic cloudflare-api-token 
  --from-literal=api-token=<YOUR_CLOUDFLARE_API_TOKEN> 
  --namespace cert-manager

ClusterIssuer‘ı bir DNS-01 çözücüyle yapılandırın:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod-dns
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: ops@example.com
    privateKeySecretRef:
      name: letsencrypt-prod-dns-account-key
    solvers:
      - dns01:
          cloudflare:
            apiTokenSecretRef:
              name: cloudflare-api-token
              key: api-token

Joker karakter sertifikasını isteyin:

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: wildcard-example-com
  namespace: production
spec:
  secretName: wildcard-example-com-tls
  issuerRef:
    name: letsencrypt-prod-dns
    kind: ClusterIssuer
  dnsNames:
    - "*.example.com"
    - example.com

Kritik tuzak: DNS sağlayıcı kimlik bilgilerini içeren Secret, bir ClusterIssuer tarafından başvurulduğunda cert-manager ad alanında bulunmalıdır. Başka bir ad alanına yerleştirirseniz, denetleyici onu okuyamaz ve düzenleme sessizce başarısız olur. Zorluklar duruyorsa cert-manager denetleyici günlüklerini kubectl logs -n cert-manager deploy/cert-manager ile kontrol edin.

CA Yayıncısı ile Dahili PKI

Bir küme içinde servisten servise mTLS için, kendinden imzalı bir kökle desteklenen bir CA yayıncısı ACME’den daha uygundur:

# Step 1: Create a self-signed root CA certificate
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: selfsigned-root
spec:
  selfSigned: {}
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: internal-root-ca
  namespace: cert-manager
spec:
  isCA: true
  commonName: internal-root-ca
  secretName: internal-root-ca-secret
  issuerRef:
    name: selfsigned-root
    kind: ClusterIssuer
---
# Step 2: Create a CA issuer backed by the root certificate
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: internal-ca-issuer
spec:
  ca:
    secretName: internal-root-ca-secret

Servisler artık herhangi bir harici CA bağımlılığı olmaksızın mTLS için internal-ca-issuer‘dan kısa ömürlü sertifikalar isteyebilir.

Yüksek Güvenlikli Ortamlar için renewBefore Yapılandırması

Varsayılan renewBefore olan 30 gün, 90 günlük Let’s Encrypt sertifikaları için uygundur. Kısa ömürlü dahili sertifikalar için (örn. 24 saatlik geçerlilik), renewBefore‘ı toplam sürenin bir kesri olarak ayarlayın:

spec:
  duration: 24h
  renewBefore: 8h

Cert-Manager, sona ermeden 8 saat önce yenilemeye başlayacak ve denetleyiciye 24 saatlik sertifika ömrü içinde üç yenileme penceresi verecektir — küme geçici API sunucusu kullanılamazlığı yaşarsa bu kritik bir güvenlik marjıdır.

Yaygın Cert-Manager Hatalarını Ayıklama

“Düzenleniyor” Durumunda Takılı Kalan Sertifika

# Check the Certificate status
kubectl describe certificate <name> -n <namespace>

# Check the associated CertificateRequest
kubectl describe certificaterequest -n <namespace>

# Check the ACME Order
kubectl describe order -n <namespace>

# Check the Challenge
kubectl describe challenge -n <namespace>

# Check controller logs
kubectl logs -n cert-manager deploy/cert-manager --tail=100

Yaygın kök nedenler:

• HTTP-01 hatası: Ingress denetleyicisi /.well-known/acme-challenge/ trafiğini doğru şekilde yönlendirmiyor. Zorluk Ingress nesnesinin oluşturulduğunu ve 80 numaralı bağlantı noktasının internetten erişilebilir olduğunu doğrulayın. Konaktaki güvenlik duvarları gelen TCP/80’e izin vermelidir.
• DNS-01 hatası: DNS sağlayıcı API token’ının yetersiz izinleri var veya DNS yayılımı tamamlanmamış. Let’s Encrypt’in doğrulama sunucuları yerel DNS’inizden farklı çözümleyiciler sorgulayabilir — 60–120 saniyelik yayılım gecikmeleri normaldir.
• Hız sınırı aşıldı: Let’s Encrypt, etki alanı başına saatte 5 başarısız doğrulama girişimi uygular. Bu sınıra ulaştıktan sonra yeniden denemeden önce beklemeniz gerekir. Her zaman önce hazırlık uç noktasıyla test edin.
• Webhook hazır değil: cert-manager webhook pod’u çalışmıyorsa, tüm CRD işlemleri bağlantı reddedildi hatasıyla başarısız olur. Webhook servisinin geçerli bir uç noktaya sahip olduğundan emin olun.

Dağıtılmış Bir Sertifikayı Doğrulama

# Check the Secret contents
kubectl get secret example-com-tls-secret -n production -o jsonpath='{.data.tls.crt}' | base64 -d | openssl x509 -noout -text

# Check expiry date specifically
kubectl get secret example-com-tls-secret -n production -o jsonpath='{.data.tls.crt}' | base64 -d | openssl x509 -noout -enddate

Üretim Sertleştirme Kontrol Listesi

Cert-Manager’ı üretim ortamında dağıtmak, varsayılan bir Helm kurulumundan daha fazlasını gerektirir. Canlıya geçmeden önce bu sertleştirme önlemlerini uygulayın:

• Kaynak sınırları: Paylaşılan düğümlerde kaynak çekişmesini önlemek için üç Cert-Manager pod’unun tamamında CPU ve bellek requests ve limits ayarlayın.
• RBAC denetimi: Cert-Manager geniş RBAC izinleri gerektirir. Kurulu ClusterRole nesnelerini inceleyin ve bunları yayıncı türleriniz için gereken minimum düzeyle sınırlayın.
• Ayrı ad alanı: Cert-Manager’ı her zaman uygulama iş yüklerinden yalıtılmış kendi cert-manager ad alanına dağıtın.
• İzleme: Cert-Manager’ın Prometheus metrik uç noktasını (--metrics-listen-address) açığa çıkarın ve yenileme hatalarını hizmetleri etkilemeden önce yakalamak için certmanager_certificate_expiration_timestamp_seconds üzerinde uyarı verin.
• CRD durumunu yedekleyin: Certificate, ClusterIssuer ve Issuer nesnelerini küme yedekleme stratejinize dahil edin. Bu manifestoları bir felaket kurtarma olayından sonra kaybetmek, tüm sertifika yapılandırmalarını manuel olarak yeniden oluşturmak anlamına gelir.
• Hazırlık doğrulaması: İlk sertifikanızı asla üretim ACME uç noktasına karşı düzenlemeyin. Hız sınırı ihlalleri etki alanınızı bir haftaya kadar engelleyebilir.

Birden fazla Kubernetes kümesi çalıştırıyorsanız — örneğin hazırlık ve üretim iş yüklerini ayırıyorsanız — VPS Control Panels, küme yaşam döngüsü yönetimini basitleştirebilir ve her kümenin üzerinde çalıştığı temel altyapıyı sağlamak için size birleşik bir arayüz sunabilir.

TLS sonlandırılmış uç noktaların arkasında GPU hızlandırmalı çıkarım veya ML sunumu gerektiren iş yükleri için, aynı Cert-Manager kalıpları GPU Hosting altyapısında da geçerlidir; burada otomatik sertifika yönetimi, model API uç noktalarının güvenliğini sağlamak için eşit derecede kritiktir.

Pratik Karar Matrisi: Doğru Yayıncıyı Seçme

Temel Çıkarımlar

• Cert-Manager’ı installCRDs=true ile Helm kullanarak kurun ve üretime geçmeden önce her zaman hazırlık ACME uç noktasına karşı doğrulayın.
• Çok ad alanlı kümeler için ClusterIssuer kullanın; ad alanı kapsamlı Issuer‘ı yalnızca ekip başına CA yalıtımına ihtiyaç duyduğunuzda kullanın.
• DNS-01, joker karakter sertifikaları ve 80 numaralı bağlantı noktasında doğrudan internetten erişilemeyen kümeler için kesinlikle gereklidir.
• renewBefore alanı üretimde isteğe bağlı değildir — sertifikanın toplam duration‘ının en az üçte birine ayarlayın.
• Düzenleme durduğunda, hata ayıklama yolu her zaman şöyledir: Certificate → CertificateRequest → Order → Challenge → denetleyici günlükleri.
• Bir ClusterIssuer tarafından başvurulan DNS sağlayıcı API kimlik bilgileri, uygulama ad alanlarında değil, cert-manager ad alanında bulunmalıdır.
• Prometheus’ta certmanager_certificate_expiration_timestamp_seconds‘ı izleyin ve uyarı verin — sessiz yenileme hataları en tehlikeli hata modudur.
• Certificate ve ClusterIssuer manifestolarınızı felaket kurtarma planınızın bir parçası olarak yedekleyin.

Sıkça Sorulan Sorular

Cert-Manager’da Issuer ile ClusterIssuer arasındaki fark nedir?

Bir Issuer ad alanı kapsamlıdır ve yalnızca tanımlandığı ad alanı içinde sertifika düzenleyebilir. Bir ClusterIssuer küme genelindedir ve herhangi bir ad alanındaki Certificate kaynakları tarafından başvurulabilir. Çoğu üretim kümesi için, katı ad alanı düzeyinde CA yalıtımına ihtiyaç duymadıkça ClusterIssuer doğru seçimdir.

Cert-Manager sertifikam neden “Düzenleniyor” durumunda takılı kalıyor?

kubectl describe kullanarak aynı ad alanındaki Order ve Challenge nesnelerini inceleyin. En yaygın nedenler şunlardır: bir güvenlik duvarı tarafından engellenen 80 numaralı bağlantı noktası (HTTP-01), yanlış DNS API kimlik bilgileri veya yayılım gecikmesi (DNS-01), Let’s Encrypt hız sınırları aşıldı veya cert-manager webhook pod’u çalışmıyor. Denetleyici günlüklerini her zaman kubectl logs -n cert-manager deploy/cert-manager ile kontrol edin.

Cert-Manager, Let’s Encrypt’ten joker karakter sertifikaları düzenleyebilir mi?

Evet, ancak yalnızca DNS-01 zorluk türünü kullanarak. HTTP-01, joker karakter etki alanlarını doğrulayamaz. ClusterIssuer çözücü yapılandırmanızda bir DNS sağlayıcı entegrasyonu (Cloudflare, Route53, vb.) yapılandırmanız ve API kimlik bilgilerinin hedef etki alanında TXT kayıtları oluşturma iznine sahip olduğundan emin olmanız gerekir.

Cert-Manager sertifika yenilemeyi otomatik olarak nasıl gerçekleştirir?

Cert-Manager’ın denetleyicisi, her Certificate nesnesinin son kullanma tarihini sürekli olarak geçerli zamanla karşılaştırır. Kalan geçerlilik renewBefore eşiğinin (varsayılan: 30 gün) altına düştüğünde, denetleyici yeni bir CertificateRequest oluşturur, ACME zorluğunu tamamlar ve sertifikayı tüketen pod’ları yeniden başlatmadan hedef Secret‘ın içeriğini atomik olarak değiştirir. Secret‘ı birim olarak bağlayan pod’lar, bir sonraki kubelet senkronizasyon döngüsünde güncellenmiş sertifikayı görecektir.

Cert-Manager yalnızca genel HTTPS için değil, dahili servisten servise iletişimi güvence altına almak için de uygun mudur?

Evet. CA yayıncısı veya HashiCorp Vault yayıncısını kullanarak Cert-Manager, mikro servisler arasındaki dahili mTLS için kısa ömürlü sertifikalar düzenleyebilir. Bu, her iş yükünün benzersiz bir kimlik sertifikasına ihtiyaç duyduğu servis ağı dağıtımlarında yaygın bir kalıptır. duration ve renewBefore alanları, sertifikaların dakikalar kadar kısa ömürlü olmasına ve tamamen otomatik rotasyona olanak tanır.