태그 보관물: https

Migrating Ingress Controller: ingress-nginx EOL to Traefik v3.7.5 with Wildcard TLS Automation

개요

kubernetes/ingress-nginx 프로젝트가 2026년 3월 31일부로 EOL(End of Life)을 선언하고 아카이브되었습니다. 이를 계기로 ingress-nginx에서 Traefik으로 마이그레이션을 진행하여 자체 관리형 Kubernetes 클러스터의 Ingress 컨트롤러를 Traefik v3.7.5로 교체하고, 모니터링 스택(Prometheus / Alertmanager / Grafana) 도메인을 *.sierracloud.dev로 전환하였습니다. 아울러 HAProxy 서버에서 관리하는 Let’s Encrypt 와일드카드 인증서를 Kubernetes 클러스터에 자동 동기화하는 CronJob을 구성하였습니다.

대안으로 Contour, Kong, HAProxy Ingress 등을 검토하였으나, Traefik을 선택한 이유는 다음과 같습니다. Helm chart가 잘 관리되고 있으며, TLSStore를 통한 와일드카드 인증서 중앙 관리가 가능합니다. 또한 CRD(IngressRoute, Middleware 등)를 통한 고급 라우팅 설정과 Kubernetes Ingress 표준 오브젝트와의 호환성을 동시에 지원합니다. HTTP → HTTPS 강제 리다이렉트도 values.yaml 설정 한 줄로 처리됩니다.


환경

  • Kubernetes v1.33.7 (HA: Control Plane 3대 + Worker 3대)
  • MetalLB — LoadBalancer IP 풀: 192.168.x.x/29
  • HAProxy (192.168.x.x:6443) — K8s API LB 및 HTTPS 리버스 프록시 겸용
  • NAS — Let’s Encrypt 인증서 원본 보관, NFS export
  • 교체 전: kubernetes/ingress-nginx v1.10.1 (EOL)
  • 교체 후: Traefik v3.7.5 (Helm chart 41.0.0)

단계별 절차

1. ingress-nginx 설정 백업

삭제 전에 기존 설정을 코드로 백업하여 재설치 시 활용할 수 있도록 보존합니다.

# IngressClass, ConfigMap, Ingress 리소스 백업
kubectl get ingressclass nginx -o yaml > backup/ingress-nginx/ingressclass-nginx.yaml
kubectl get cm ingress-nginx-controller -n ingress-nginx -o yaml > backup/ingress-nginx/configmap-controller.yaml
kubectl get ingress -n monitoring -o yaml > backup/ingress-nginx/ingress-monitoring.yaml

# Helm values 백업
helm get values ingress-nginx -n ingress-nginx -o yaml > backup/ingress-nginx/helm-ingress-nginx-values.yaml

# 삭제 절차 문서화 후 제거
helm uninstall ingress-nginx -n ingress-nginx

2. Traefik v3.7.5 설치

ingress-nginx가 사용하던 MetalLB IP를 그대로 유지하여 HAProxy의 백엔드 설정 변경 없이 전환합니다.

helm repo add traefik https://traefik.github.io/charts
helm repo update

helm upgrade --install traefik traefik/traefik \
  -f helm/traefik-values.yaml \
  -n traefik --create-namespace

helm/traefik-values.yaml 핵심 설정:

service:
  annotations:
    metallb.universe.tf/loadBalancerIPs: "192.168.x.x"   # 기존 IP 유지

ingressClass:
  enabled: true
  isDefaultClass: true

ports:
  web:
    http:
      redirections:
        entryPoint:
          to: websecure
          scheme: https
          permanent: true   # HTTP → HTTPS 전체 리다이렉트

3. 모니터링 도메인 변경

*.sierracloud.kro.kr에서 *.sierracloud.dev로 전환하고 ingressClassName을 교체합니다. Helm values 수정 후 upgrade를 적용합니다.

# helm/monitoring-values.yaml (변경 부분)
prometheus:
  ingress:
    ingressClassName: traefik    # nginx → traefik
    hosts:
      - prometheus.sierracloud.dev

grafana:
  ingress:
    ingressClassName: traefik
    hosts:
      - grafana.sierracloud.dev
  grafana.ini:
    server:
      domain: grafana.sierracloud.dev
      root_url: https://grafana.sierracloud.dev
      protocol: http             # Traefik이 TLS 종료, Grafana 내부는 HTTP
helm upgrade monitoring prometheus-community/kube-prometheus-stack \
  -f helm/monitoring-values.yaml -n monitoring

4. 와일드카드 TLS 인증서 자동화

HAProxy 서버에서 certbot이 Let’s Encrypt 인증서를 주기적으로 갱신하고 NAS에 복사합니다. Kubernetes CronJob이 이후 NAS NFS를 마운트하여 SHA256 비교 후 변경 시에만 Secret을 갱신합니다.

certbot (HAProxy)
  └─→ NAS (NFS)
        └─→ K8s CronJob (SHA256 비교)
              └─→ traefik/wildcard-sierracloud-dev Secret
                    └─→ Traefik TLSStore default → 모든 서비스 자동 적용

TLSStore를 사용하면 각 네임스페이스의 Ingress 리소스에 secretName을 지정할 필요 없이 모든 HTTPS 라우트에 와일드카드 인증서가 자동으로 적용됩니다.

# manifests/traefik/tls-store.yaml
apiVersion: traefik.io/v1alpha1
kind: TLSStore
metadata:
  name: default
  namespace: traefik
spec:
  defaultCertificate:
    secretName: wildcard-sierracloud-dev

CronJob은 매주 갱신 주기에 맞춰 실행되며 SHA256 비교를 통해 인증서가 변경된 경우에만 Secret을 업데이트합니다.

# manifests/traefik/tls-secret-sync.yaml (핵심 부분)
schedule: "30 6 * * 1"    # 매주 월요일
timeZone: "Asia/Seoul"
concurrencyPolicy: Forbid

volumes:
  - name: certs
    nfs:
      server: 192.168.x.x
      path: /data/cert
      readOnly: true
# CronJob 컨테이너 스크립트 (요약)
CURRENT_SHA=$(kubectl get secret wildcard-sierracloud-dev -n traefik \
  -o jsonpath='{.data.tls\.crt}' | base64 -d | sha256sum | cut -d' ' -f1)
NEW_SHA=$(sha256sum < /certs/sierracloud.dev/fullchain.pem | cut -d' ' -f1)

if [ "$CURRENT_SHA" != "$NEW_SHA" ]; then
  kubectl create secret tls wildcard-sierracloud-dev \
    --cert=/certs/sierracloud.dev/fullchain.pem \
    --key=/certs/sierracloud.dev/privkey.pem \
    -n traefik --dry-run=client -o yaml | kubectl apply -f -
fi

트러블슈팅

① bitnami/kubectl 이미지 태그 없음

증상: CronJob 컨테이너 이미지 bitnami/kubectl:1.33이 ImagePullBackOff 발생.

원인: 2025년 12월 이후 bitnami/kubectl Docker Hub 레포지토리에서 버전 태그가 삭제됨 (GitHub issue #88999). latest 태그만 존재.

해결: alpine/k8s:1.33.10으로 교체. Alpine 기반으로 kubectl + 기본 유틸리티(sha256sum, base64 등) 포함, K8s 1.33.x 버전과 동일 minor version으로 완전 호환.

image: alpine/k8s:1.33.10    # bitnami/kubectl:1.33 → 교체

② 도메인 변경 후 Traefik 503 (약 5초)

증상: Helm upgrade 직후 prometheus.sierracloud.dev, grafana.sierracloud.dev 접속 시 503 반환.

원인: Traefik이 새로운 Ingress 라우트를 동기화하는 데 약 5초 소요.

해결: 별도 조치 없이 자연 해소. Traefik의 정상적인 라우트 갱신 동작.


검증

# Traefik LoadBalancer IP 확인
kubectl get svc -n traefik

# TLSStore 적용 확인
kubectl get tlsstore -n traefik

# Secret 인증서 유효기간 확인
kubectl get secret wildcard-sierracloud-dev -n traefik \
  -o jsonpath='{.data.tls\.crt}' | base64 -d | openssl x509 -noout -subject -dates

# HTTPS 접속 확인
curl -skI https://grafana.sierracloud.dev | head -3
curl -skI https://prometheus.sierracloud.dev | head -3
# 출력 예시
HTTP/2 302       ← Grafana 로그인 리다이렉트 (정상)
HTTP/2 405       ← Prometheus (정상)

subject=CN = *.sierracloud.dev
notAfter=Sep 17 13:39:09 2026 GMT

결론

ingress-nginx EOL 전환을 계기로 Traefik v3.7.5를 도입하고, Let’s Encrypt 와일드카드 인증서의 자동 갱신 파이프라인을 구성하였습니다. Secret을 traefik 네임스페이스에 단일 관리하고 TLSStore default로 노출함으로써 향후 신규 서비스 추가 시 Ingress에 secretName을 별도 지정할 필요 없이 자동으로 와일드카드 인증서가 적용됩니다.

기존 ingress-nginx와의 전환 과정에서 MetalLB LoadBalancer IP를 그대로 유지했기 때문에 HAProxy 백엔드 설정 변경 없이 완전한 무중단 전환이 가능하였습니다. Traefik v3 계열의 Kubernetes Gateway API 지원, 향상된 observability, 그리고 CRD 기반의 미들웨어 체인 설정은 장기적인 운영에서도 ingress-nginx 대비 유리한 점이 많습니다.

참고

관련 포스트:

참고 문서: Traefik TLSStore Default Certificate (공식 문서) · Traefik Helm Chart 설치 가이드

아파치 https 구성

개요

Apache에서 HTTPS 구성을 위해 mod_ssl 모듈을 설치하고 OpenSSL로 Self-Signed 인증서를 생성한 후, ssl.conf와 httpd.conf에 적용하는 방법을 정리합니다. 실제 서비스에서는 공인 CA(Let’s Encrypt 등)의 인증서 사용을 권장하지만, 내부망이나 테스트 환경에서는 Self-Signed 인증서로 HTTPS를 빠르게 구성할 수 있습니다.

※ CentOS 6.x 기준으로 작성된 내용입니다. 아파치를 컴파일로 설치했을 경우 mod_ssl도 다시 컴파일로 설치를 진행해야 합니다.

HTTPS 구성 원리

HTTPS는 HTTP 통신을 TLS(Transport Layer Security)로 암호화하는 프로토콜입니다. 서버는 인증서(.crt)와 개인키(.key)를 보유하며, 클라이언트가 접속하면 TLS 핸드셰이크를 통해 인증서를 교환하고 세션 키를 협상합니다. Self-Signed 인증서는 서버 자신이 서명하므로 브라우저 신뢰 저장소에 없어 경고가 뜨지만, 내부망 서비스 암호화에는 충분합니다.

Apache에서 HTTPS를 구성하려면 mod_ssl 모듈이 필요합니다. CentOS/RHEL에서는 yum으로 설치하며, 컴파일 설치 방식의 Apache라면 --enable-ssl 옵션을 포함해 재컴파일해야 합니다. 설치 후 /etc/httpd/conf.d/ssl.conf 파일이 생성되며 이 파일에서 인증서 경로와 TLS 버전을 제어합니다.

mod_ssl, openssl 설치

mod_ssl과 openssl이 설치되어 있지 않다면 yum으로 설치합니다.

# 설치 여부 확인
# rpm -qa | grep -E "mod_ssl|openssl"

# yum install mod_ssl openssl -y

Self-Signed 인증서 생성

OpenSSL 명령으로 개인키(ca.key), CSR(ca.csr), Self-Signed 인증서(ca.crt)를 순서대로 생성한 후 Apache가 참조하는 경로에 복사합니다.

# 개인키 생성
# openssl genrsa -out ca.key 1024

# CSR(Certificate Signing Request) 생성
# openssl req -new -key ca.key -out ca.csr
# 국가/주(도)/시/사명//도메인(hostname)/// 영문으로 각 항목 입력

# Self-Signed 인증서 생성 (유효기간 10년)
# openssl x509 -req -days 3650 -in ca.csr -signkey ca.key -out ca.crt

# 생성 키 복사
# cp ca.crt /etc/pki/tls/certs/
# cp ca.key /etc/pki/tls/private/ca.key
# cp ca.csr /etc/pki/tls/private/ca.csr

# SELinux 활성화 환경에서 컨텍스트 복구 필요 시
# restorecon -RvF /etc/pki

ssl.conf 설정

/etc/httpd/conf.d/ssl.conf에서 인증서 파일 경로를 생성한 파일 경로로 수정합니다.

# /etc/httpd/conf.d/ssl.conf 수정 — 경로 및 파일명 수정
SSLCertificateFile /etc/pki/tls/certs/ca.crt
SSLCertificateKeyFile /etc/pki/tls/private/ca.key

httpd.conf 설정

HTTPS VirtualHost를 추가하고 HTTP 요청을 HTTPS로 리다이렉트하는 rewrite 규칙을 설정합니다. Apache 2.4에서는 NameVirtualHost 지시자가 불필요합니다.

# /etc/httpd/conf/httpd.conf에 추가
# NameVirtualHost *:443  <-- Apache 2.4에서는 삭제
<VirtualHost *:443>
  SSLEngine on
  SSLCertificateFile /etc/pki/tls/certs/ca.crt
  SSLCertificateKeyFile /etc/pki/tls/private/ca.key
  ServerAdmin admin@<domain>
  DocumentRoot /var/www/html
  ServerName <domain>
  ErrorLog logs/ssl_error_log
  CustomLog logs/ssl_access_log common
</VirtualHost>

# HTTP → HTTPS 리다이렉트 (mod_rewrite 활성화 필요)
<VirtualHost *:80>
  RewriteEngine On
  RewriteCond %{HTTPS} !=on
  RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]
</VirtualHost>

서비스 재시작 및 확인

Apache를 재시작한 후 80/443 포트 리슨 상태를 확인하고, 브라우저에서 HTTP 접속 시 HTTPS로 리다이렉션되는지 확인합니다.

# CentOS 6.x
# service httpd restart

# CentOS 7.x
# systemctl restart httpd

# 80, 443 포트 리슨 확인
# netstat -ntlp

# 브라우저에서 http://<서버IP> 접속 후 https로 리다이렉션 여부 확인

Self-Signed 인증서 한계와 공인 인증서 전환

Self-Signed 인증서는 브라우저에서 “신뢰할 수 없는 인증서” 경고를 표시합니다. 사용자가 직접 예외를 추가해야 하며, 모바일 브라우저나 API 클라이언트에서는 연결 자체가 거부되기도 합니다. 외부 사용자가 접근하는 서비스라면 Let’s Encrypt 등 공인 CA에서 무료 인증서를 발급받아 적용하는 것이 권장됩니다.

현재 적용된 인증서 유효기간과 발급자는 OpenSSL 명령으로 확인합니다.

# 도메인 인증서 정보 확인 (원격)
openssl s_client -connect <domain>:443 < /dev/null 2>/dev/null | openssl x509 -noout -dates -subject

# 파일로 인증서 정보 확인
openssl x509 -in /etc/pki/tls/certs/ca.crt -noout -dates -subject

인증서 갱신 시에는 새 인증서와 키 파일을 기존 경로에 덮어쓴 뒤 systemctl reload httpd로 중단 없이 새 인증서를 반영할 수 있습니다. restart와 달리 reload는 Apache를 재시작하지 않고 설정만 다시 읽으므로 기존 연결을 끊지 않습니다.

참고

참고 문서: Apache SSL/TLS How-To 공식 문서 · OpenSSL req 명령어 문서