Kubernetes 101 (5/10): Ingress

티스토리 뷰

Software Engineering

Kubernetes 101 (5/10): Ingress

최영선 2026. 6. 2. 23:14

Service까지 배우면 클러스터 내부 통신은 어느 정도 정리됩니다. 하지만 사용자가 브라우저나 앱에서 요청을 보내기 시작하면 다른 질문이 생깁니다. 외부 트래픽을 어디서 받을지, 여러 서비스를 어떤 규칙으로 나눌지, TLS 인증서를 어디에서 종료할지를 정해야 합니다.

이 글은 Kubernetes 101 시리즈의 5번째 글입니다.

여기서는 Ingress를 단순한 외부 노출 기능이 아니라, 여러 서비스를 하나의 진입점 뒤에 두고 HTTP 계층에서 라우팅 규칙과 TLS 종료를 모으는 구조로 정리하겠습니다.

Ingress는 외부 노출 기능이 아니라 '여러 서비스를 하나의 진입점 뒤에 두고 HTTP 계층에서 라우팅과 TLS를 모으는 자리'입니다 — 도메인·경로 규칙·인증서 종료가 각 Service에 흩어지지 않고 한 곳에 모일 때 운영 일관성이 비로소 생깁니다.

먼저 던지는 질문

Ingress와 IngressController는 왜 따로 이해해야 할까요?
여러 서비스를 하나의 도메인 아래에서 어떻게 나눌 수 있을까요?
host, path, pathType은 어떤 차이를 만들까요?

왜 중요한가

서비스 수가 적을 때는 앱마다 LoadBalancer Service를 하나씩 두는 방법도 가능해 보입니다. 하지만 서비스가 늘어나면 외부 IP, 인증서, 라우팅 정책, 보안 정책이 모두 흩어집니다. 구조가 단순해 보이는 대신 운영 부담과 비용이 빠르게 커집니다.

Ingress는 이 문제를 해결하기 위한 공통 진입점입니다. 중요한 점은 Ingress 자체가 프록시가 아니라 규칙 객체라는 사실입니다. 규칙과 실행체를 분리해서 이해해야, 왜 규칙은 있는데 트래픽이 안 들어오는지 같은 문제를 빠르게 파악할 수 있습니다.

한눈에 보는 구조

외부 로드 밸런서는 보통 클러스터 앞단에서 트래픽을 받아들이고, IngressController는 Ingress 규칙을 실제 프록시 동작으로 바꿉니다. 결국 Ingress는 "어디로 보낼지"를 선언하고, Controller는 "어떻게 보낼지"를 실행합니다.

핵심 용어

Ingress: L7 HTTP 라우팅 규칙을 담는 객체입니다.
IngressController: Ingress 규칙을 실제 프록시 설정으로 적용하는 실행체입니다.
host: 도메인 이름입니다.
path: URL 경로입니다.
TLS 종료: HTTPS 복호화를 Ingress 지점에서 처리하는 방식입니다.

도입 전과 후

Ingress가 없으면 서비스마다 외부 LoadBalancer를 따로 두기 쉽습니다. 처음에는 이해하기 쉽지만, 비용과 인증서 운영 부담이 빠르게 커집니다.

Ingress를 두면 하나의 진입점 뒤에서 /api는 API 서비스로, /는 웹 서비스로 보내는 식의 라우팅을 중앙에서 선언할 수 있습니다. 외부 노출 구조가 훨씬 읽기 쉬워지는 이유입니다.

단계별로 호스트와 경로 라우팅 구성하기

1단계 — Ingress 매니페스트 작성

"""
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata: {name: web}
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service: {name: api, port: {number: 80}}
      - path: /
        pathType: Prefix
        backend:
          service: {name: web, port: {number: 80}}
"""

이 예제는 example.com/api를 api 서비스로 보내고, 나머지 / 요청은 web 서비스로 보냅니다. 여기서 먼저 볼 값은 host, path, pathType입니다.

2단계 — 적용

import subprocess

def apply(path):
    subprocess.run(["kubectl", "apply", "-f", path], check=True)

Ingress를 적용했다고 해서 바로 트래픽이 흐르지는 않습니다. 클러스터 안에 IngressController가 있어야 이 규칙이 실제 프록시 동작으로 이어집니다.

3단계 — TLS 시크릿 생성

def tls_secret(name, cert, key):
    subprocess.run([
        "kubectl", "create", "secret", "tls", name,
        "--cert", cert, "--key", key,
    ], check=True)

TLS는 보통 Secret으로 관리합니다. 인증서와 개인 키는 해당 Ingress와 같은 네임스페이스에 둬야 HTTPS가 제대로 붙습니다.

4단계 — TLS 적용

"""
spec:
  tls:
  - hosts: [example.com]
    secretName: example-tls
"""

이 설정을 추가하면 애플리케이션 컨테이너마다 인증서를 따로 둘 필요 없이, 공통 진입점에서 HTTPS를 종료할 수 있습니다. 운영 관점에서 큰 단순화입니다.

5단계 — 확인

def curl(host, path):
    res = subprocess.run(
        ["curl", "-sk", f"https://{host}{path}"],
        capture_output=True, text=True, check=True,
    )
    return res.stdout

실제 요청을 보내 보면 경로별 라우팅과 TLS 적용 여부를 함께 검증할 수 있습니다. /api와 /를 각각 호출해 다른 응답이 오는지 보는 방식이 가장 직관적입니다.

검증 흐름

kubectl get ingress web
kubectl describe ingress web
curl -sk -H 'Host: example.com' https://<ingress-address>/api

예상되는 결과: get ingress에는 address 또는 controller가 붙인 엔드포인트가 보이고, describe에는 호스트·경로·백엔드 서비스가 명시돼야 합니다. 마지막 curl에서는 /api 요청이 웹 루트와 다른 백엔드로 흘렀다는 흔적을 응답으로 확인합니다.

먼저 의심할 실패 모드:

Ingress 객체만 있고 address가 비어 있으면 규칙이 아니라 controller 설치 상태를 먼저 봐야 합니다.
TLS handshake가 실패하면 인증서 자체보다 Secret 네임스페이스와 secretName 오타를 먼저 점검합니다.
/는 되는데 /api가 엉뚱한 서비스로 가면 path 우선순위와 pathType 해석이 어긋난 경우가 많습니다.

이 코드에서 먼저 봐야 할 점

Ingress는 규칙이고 Controller는 실행체입니다.
pathType: Prefix는 가장 흔한 기본 선택입니다.
TLS는 Ingress 지점에서 종료할 수 있습니다.

이 세 가지를 구분하면 Ingress를 단순 포워더로 보지 않게 됩니다. 규칙 객체, 실행 컨트롤러, 외부 진입점이 서로 다른 역할을 갖고 있다는 사실이 보입니다.

자주 하는 실수 다섯 가지

IngressController가 없는데도 Ingress만 만들면 외부 요청이 들어올 것이라 생각합니다.
pathType을 생략해 구현체별 차이와 호환성 문제를 만납니다.
TLS Secret을 잘못된 네임스페이스에 둡니다.
서비스마다 LoadBalancer를 계속 만들어 비용 문제를 키웁니다.
경로 우선순위를 잘못 이해해 다른 백엔드로 요청을 보냅니다.

실무에서는 이렇게 봅니다

실무에서는 nginx-ingress, AWS Load Balancer Controller 같은 구현이 Ingress 객체를 읽어 실제 프록시와 외부 로드 밸런서 구성을 맞춥니다. TLS는 cert-manager와 묶어 자동 발급과 자동 갱신까지 연결하는 경우가 많습니다.

시니어 엔지니어는 Ingress 문법만 보지 않고, 지금 쓰는 Controller가 어떤 기능과 제약을 갖는지도 함께 봅니다. 같은 Ingress 객체라도 구현체마다 동작 범위가 다를 수 있기 때문입니다. Gateway API가 주목받는 이유도 이 지점과 이어집니다.

체크리스트

IngressController가 설치되어 있는가
pathType을 명시했는가
TLS 자동화 방안을 준비했는가
외부 진입점을 가능한 한 통합했는가

연습 문제

Ingress와 IngressController의 차이를 한 줄로 설명해 보세요.
TLS 종료를 Ingress에서 처리할 때 좋은 점을 하나 적어 보세요.
Gateway API가 해결하려는 한계를 한 줄로 정리해 보세요.

마무리와 다음 글

이 글에서는 Ingress를 여러 서비스를 하나의 외부 진입점 뒤에 두고, 도메인과 경로 기준으로 HTTP 요청을 나누는 규칙 객체로 정리했습니다. 실제 동작은 IngressController가 책임지고, TLS 종료까지 이 지점에 모으면 외부 노출 구조가 훨씬 단순해집니다.

다음 글에서는 네트워크 경로가 아니라 애플리케이션 설정과 민감한 값을 어떻게 분리하는지, ConfigMap과 Secret을 보겠습니다.

매니페스트 중심 운영 예시

Kubernetes의 강점은 명령형 조작보다 선언형 매니페스트에 있습니다. 아래 예시는 Deployment, Service, Ingress를 분리해 책임 경계를 명확히 둔 기본 형태입니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
  labels:
    app: api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
        - name: api
          image: ghcr.io/example/api:1.2.0
          ports:
            - containerPort: 8000
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8000
            initialDelaySeconds: 5
            periodSeconds: 10
          resources:
            requests:
              cpu: "200m"
              memory: "256Mi"
            limits:
              cpu: "500m"
              memory: "512Mi"
---
apiVersion: v1
kind: Service
metadata:
  name: api
spec:
  selector:
    app: api
  ports:
    - port: 80
      targetPort: 8000
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api
spec:
  ingressClassName: nginx
  rules:
    - host: api.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: api
                port:
                  number: 80

readiness probe와 resource request/limit를 함께 정의하면 "배포는 되었지만 트래픽을 받으면 무너지는" 상태를 줄일 수 있습니다. 선언형 파일에서 운영 안정성을 미리 포함시키는 방식이 중요합니다.

kubectl 운영 명령 모음

매니페스트를 적용한 뒤에는 상태 관찰 명령을 빠르게 순환해야 합니다. 아래 조합은 장애 분석에서 가장 자주 사용하는 기본 세트입니다.

kubectl apply -f k8s/
kubectl get deploy,rs,pod -n prod -o wide
kubectl rollout status deploy/api -n prod
kubectl describe pod -n prod -l app=api
kubectl logs -n prod deploy/api --tail=200
kubectl get events -n prod --sort-by=.metadata.creationTimestamp

rollout status와 describe를 먼저 보면 이미지 pull 실패, probe 실패, 스케줄링 실패를 빠르게 구분할 수 있습니다. 로그만 먼저 보면 인프라 원인을 애플리케이션 오류로 오판하기 쉽습니다.

아키텍처 관점에서 봐야 할 경계

API Server 경계: 모든 선언 변경은 API 서버를 통과합니다. 직접 노드에 접속해 상태를 손으로 맞추는 방식은 drift를 만듭니다.
Scheduler 경계: Pod 배치는 자원 요청, taint/toleration, affinity 규칙의 결과입니다. 노드 선택 문제는 애플리케이션 버그와 분리해 봐야 합니다.
Controller 경계: Deployment Controller는 replica 수렴과 롤링 업데이트를 담당합니다. desired/current 값 차이를 관찰하는 습관이 핵심입니다.
Network 경계: Service와 Ingress는 L4/L7 책임이 다릅니다. 내부 통신 실패와 외부 진입 실패를 분리해 진단해야 대응이 빨라집니다.

이 경계를 기준으로 장애를 분해하면 "클러스터 문제"라는 모호한 결론 대신, 어느 계층에서 어떤 신호가 깨졌는지 명확히 남길 수 있습니다.

배포 안정성을 높이는 실무 체크

모든 워크로드에 readiness/liveness probe를 설정합니다.
latest 태그 대신 고정 버전 태그를 사용해 롤백 기준을 확보합니다.
변경 전 kubectl diff -f로 영향을 검토해 무의식적 설정 누락을 줄입니다.
운영 네임스페이스에는 ResourceQuota와 LimitRange를 적용해 폭주 범위를 제한합니다.
배포 후 kubectl rollout history를 확인해 복구 경로를 문서화합니다.

Kubernetes는 기능이 많아서 어려운 도구가 아니라, 경계를 나누어 관찰하지 않으면 쉽게 혼란스러워지는 도구입니다. 매니페스트, 관찰 명령, 아키텍처 경계를 함께 묶어 운영하면 학습 속도와 안정성이 동시에 올라갑니다.

Ingress 규칙을 운영 가능한 형태로 작성하기

Ingress는 "들어오는 길"을 만드는 리소스입니다. 경로 기반 라우팅, TLS, 리다이렉트를 한 파일에 섞어 쓰기보다 목적별로 나눠 관리하면 변경 영향이 줄어듭니다.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web
  annotations:
    nginx.ingress.kubernetes.io/proxy-body-size: "10m"
    nginx.ingress.kubernetes.io/proxy-read-timeout: "60"
spec:
  ingressClassName: nginx
  tls:
    - hosts: ["app.example.com"]
      secretName: app-example-com-tls
  rules:
    - host: app.example.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: api
                port:
                  number: 80

404/502 트러블슈팅 루틴

kubectl describe ingress web -n prod
kubectl get ingress web -n prod -o yaml
kubectl logs -n ingress-nginx deploy/ingress-nginx-controller --tail=200
kubectl get svc api -n prod
kubectl get endpoints api -n prod

404는 경로/호스트 매칭 실패를 먼저 의심합니다.
502는 백엔드 Service/Endpoints 연결 상태를 먼저 봅니다.
TLS 오류는 Secret 유효기간과 호스트 SAN 불일치를 먼저 확인합니다.

Ingress는 애플리케이션 팀과 플랫폼 팀의 경계가 만나는 지점입니다. 규칙 변경 시 리뷰 체계를 두면 장애를 크게 줄일 수 있습니다.

운영 시뮬레이션 확장

Ingress 관점의 문서를 읽고 끝내면 실제 운영에서 금방 잊힙니다. 그래서 학습 직후에 "장애를 일부러 만들어 보고 복구하는" 시뮬레이션을 반드시 권장합니다. 여기서 중요한 점은 성공 데모를 반복하는 것이 아니라, 실패 신호를 표준 절차로 읽는 훈련을 하는 것입니다. 팀이 성장할수록 기술 격차보다 절차 격차가 더 큰 장애를 만듭니다.

먼저 시뮬레이션 전 공통 기준을 맞춥니다. 대상 네임스페이스를 분리하고, 적용한 매니페스트의 Git SHA를 기록하고, 관찰 명령 5개를 고정합니다. 이 기준이 있어야 "누가, 어떤 상태에서, 무엇을 바꿨는지"를 추적할 수 있습니다.

kubectl config current-context
kubectl get ns
kubectl get deploy,po,svc,ing -n prod -o wide
kubectl get events -n prod --sort-by=.metadata.creationTimestamp
kubectl top pod -n prod

다음으로 장애 주입 시나리오를 단계적으로 실행합니다. 첫째, 잘못된 이미지 태그를 넣어 ImagePullBackOff를 발생시킵니다. 둘째, readiness probe 경로를 의도적으로 틀려 Ready 전환 실패를 만듭니다. 셋째, 메모리 limit를 과도하게 낮춰 OOM 재시작을 유도합니다. 넷째, selector 불일치를 만들어 트래픽 블랙홀을 재현합니다. 이 네 가지는 초급 팀이 실제 운영에서 가장 자주 만나는 장애 패턴입니다.

kubectl set image deploy/api api=ghcr.io/example/api:not-found -n prod
kubectl rollout status deploy/api -n prod
kubectl describe pod -n prod -l app=api
kubectl logs -n prod deploy/api --previous
kubectl rollout undo deploy/api -n prod

복구 절차는 항상 동일한 순서를 사용합니다. 1) 영향 범위 확인, 2) 즉시 완화(rollback/scale), 3) 원인 확인, 4) 재발 방지 반영입니다. 순서를 바꾸면 현장에서 토론만 길어지고 복구는 늦어집니다. 특히 온콜 시간대에는 "정확한 분석"보다 "안전한 복구"를 먼저 해야 합니다.

운영 품질을 높이려면 기술 항목을 문서 항목으로 바꿔야 합니다. 예를 들어 "probe를 잘 설정한다"가 아니라 "모든 워크로드는 readiness/liveness를 필수로 포함하고, 경로는 헬스 라우터 표준(/readyz, /livez)을 사용한다"처럼 검증 가능한 규칙으로 적어야 합니다. 또 "리소스를 적절히 준다" 대신 "CPU request는 최근 7일 P50의 1.3배, memory limit는 P99의 1.2배" 같은 팀 기준선을 고정하면 논쟁 비용이 줄어듭니다.

런북에 남겨야 할 최소 항목

장애 유형별 최초 확인 명령 3개
즉시 완화 명령과 금지 명령
롤백 기준 버전과 검증 체크리스트
관련 대시보드 링크와 알림 임계치
동일 유형 재발 시 담당 팀 에스컬레이션 경로

문서를 이 수준으로 남기면 신규 팀원이 들어와도 대응 품질이 유지됩니다. Kubernetes 운영 성숙도는 기능 사용량이 아니라 "동일 장애를 같은 속도로 복구할 수 있는가"로 측정하는 편이 정확합니다.

실무 검증 체크포인트

운영에서 변경을 배포할 때는 코드 리뷰와 별도로 클러스터 검증 체크를 둬야 합니다. 체크 항목은 복잡할 필요가 없습니다. 적용 전 kubectl diff, 적용 후 rollout status, 엔드포인트 연결 확인, 로그 샘플 확인, 자원 사용률 확인 정도만 일관되게 수행해도 대다수 실수를 초기에 차단할 수 있습니다.

kubectl diff -f k8s/ -n prod
kubectl apply -f k8s/ -n prod
kubectl rollout status deploy/api -n prod
kubectl get endpoints api -n prod
kubectl top pod -n prod -l app=api

여기서 마지막으로 중요한 원칙은 "수동 핫픽스를 원복 가능한 상태로 남긴다"는 점입니다. 긴급 대응 중에 kubectl edit로 해결했다면, 근무 종료 전에 반드시 매니페스트에 같은 변경을 반영해 drift를 없애야 합니다. 선언형 시스템에서 drift는 시간이 지날수록 큰 장애로 돌아옵니다.

관측성과 보안 기본선

Kubernetes 학습이 진행될수록 기능 사용량은 늘어나지만, 실제 장애를 줄이는 요소는 관측성과 보안 기본선입니다. 최소한 애플리케이션 로그, 인프라 이벤트, 자원 메트릭이 같은 시간축에서 비교 가능해야 하고, 서비스 계정 권한과 시크릿 접근 범위가 분리되어 있어야 합니다. 이 두 축이 약하면 배포 속도가 빨라질수록 실패 속도도 같이 빨라집니다.

관측성 기본선은 거창할 필요가 없습니다. 워크로드마다 공통 레이블(app, component, version)을 강제하고, 로그에 요청 식별자와 에러 코드를 남기고, 대시보드에서 레이블 필터로 바로 분해할 수 있으면 됩니다. 이벤트 스트림까지 함께 보면 "배포 변경"과 "오류 급증"의 시간적 상관관계를 빠르게 확인할 수 있습니다.

kubectl get events -n prod --sort-by=.metadata.creationTimestamp
kubectl logs -n prod deploy/api --since=10m
kubectl top pod -n prod -l app=api
kubectl top node

보안 기본선에서는 RBAC 최소 권한 원칙을 먼저 적용하세요. 운영 계정이 모든 네임스페이스에 쓰기 권한을 가지면 단기적으로는 편하지만, 실수 한 번이 전체 서비스로 번질 수 있습니다. 네임스페이스 단위 Role/RoleBinding을 기본으로 두고, 클러스터 전역 권한은 예외 승인 절차를 거치도록 설계하는 편이 안전합니다.

또한 NetworkPolicy를 도입하면 "통신이 되는 것이 기본"인 상태를 "허용한 통신만 된다"는 상태로 바꿀 수 있습니다. 초기에는 DNS, 내부 API, 데이터베이스 같은 필수 경로부터 열고, 나머지는 점진적으로 차단하는 방식이 현실적입니다. 정책은 기능이 아니라 운영 안전장치입니다.

마지막으로, 변경 후 검증을 자동화하세요. kubectl apply 이후에 상태 확인 명령을 사람이 매번 동일하게 수행하기 어렵기 때문에, CI에서 kubectl diff, kubeconform류 스키마 체크, 서버 사이드 dry-run을 묶어 두면 기본 결함을 배포 전에 차단할 수 있습니다. Kubernetes 운영 성숙도는 고급 기능보다 "기본 검증을 빠짐없이 반복하는 능력"에서 먼저 올라갑니다.

최종 점검 메모

배포 전 마지막 점검은 단순하지만 효과가 큽니다. 첫째, 이번 변경이 어느 리소스에 영향을 주는지 kubectl diff로 확인합니다. 둘째, 적용 후 rollout status가 끝날 때까지 기다리고, 이벤트 로그에서 경고 신호가 없는지 확인합니다. 셋째, 사용자 경로 기준 헬스 체크를 직접 호출해 응답 코드와 지연 시간을 기록합니다. 넷째, 이전 안정 버전으로 되돌릴 명령을 미리 준비해 둡니다.

kubectl diff -f k8s/ -n prod
kubectl rollout status deploy/api -n prod
kubectl get events -n prod --sort-by=.metadata.creationTimestamp
curl -fsS https://app.example.com/healthz

이 네 단계를 표준화하면 변경 속도가 빨라져도 운영 안정성을 유지하기 쉽습니다.

운영 한 줄 원칙

운영에서 가장 중요한 원칙은 "원인 추정 전에 상태 증거를 먼저 수집한다"입니다. describe, events, rollout 세 신호를 먼저 확보하면 잘못된 가정으로 시간을 쓰는 일을 줄일 수 있습니다.

운영 중에는 변경 직후 10분 관찰 창을 두고 경고 이벤트를 반드시 확인합니다.

처음 질문으로 돌아가기

Ingress와 IngressController는 왜 따로 이해해야 할까요?
- Ingress는 호스트와 경로별 라우팅 규칙을 적어 둔 "선언"일 뿐이고, 그 선언을 실제로 받아 nginx·HAProxy·Envoy 같은 프록시로 변환해 트래픽을 처리하는 일은 IngressController가 맡습니다. 본문에서 보듯 Controller가 없는 클러스터에 Ingress만 만들어 두면 어떤 라우팅도 일어나지 않습니다.
여러 서비스를 하나의 도메인 아래에서 어떻게 나눌 수 있을까요?
- 본문의 host와 path 기반 규칙처럼 같은 도메인의 /api는 API Service로, /admin은 관리자 Service로 보내거나, 서브도메인별로 다른 Service에 매핑할 수 있습니다. 즉 LoadBalancer를 서비스마다 새로 띄우지 않고 L7 라우팅으로 외부 진입점을 하나로 모을 수 있습니다.
host, path, pathType은 어떤 차이를 만들까요?
- host는 어느 도메인 트래픽인지를, path는 그 안에서 어느 경로 묶음인지를 결정하고, pathType(Prefix·Exact·ImplementationSpecific)은 그 경로 매칭이 접두사인지 정확 일치인지 컨트롤러 재량인지를 결정합니다. 본문에서 강조한 대로 pathType을 비워 두면 컨트롤러마다 동작이 달라져 의도와 다른 라우팅이 일어나기 쉽습니다.

시리즈 목차

Kubernetes 101 (1/10): Kubernetes란 무엇인가?
Kubernetes 101 (2/10): Pod
Kubernetes 101 (3/10): Deployment
Kubernetes 101 (4/10): Service
Ingress (현재 글)
ConfigMap과 Secret (예정)
Volume (예정)
HPA (예정)
Helm (예정)
운영 관점의 Kubernetes (예정)

참고 자료

'Software Engineering' 카테고리의 다른 글

Kubernetes 101 (7/10): Volume (0)	2026.06.02
Kubernetes 101 (6/10): ConfigMap과 Secret (0)	2026.06.02
Kubernetes 101 (4/10): Service (0)	2026.06.02
Kubernetes 101 (3/10): Deployment (0)	2026.06.02
Kubernetes 101 (2/10): Pod (0)	2026.06.02

공지사항

최근에 올라온 글

최근에 달린 댓글

Total

Today

Yesterday

링크

TAG more

« 2026/06 »
일	월	화	수	목	금	토
	1	2	3	4	5	6
7	8	9	10	11	12	13
14	15	16	17	18	19	20
21	22	23	24	25	26	27
28	29	30

글 보관함

최영선의 블로그

티스토리 뷰