버전: 1.0.3

5.1. 네트워크

어떨 때 보는가

배포한 애플리케이션에 접속되지 않을 때
외부 접속 주소를 확인할 때
서비스끼리 통신이 막혀 있을 때

파드 주소는 왜 문제인가

파드는 만들어질 때마다 새 IP 주소를 받습니다. 다시 만들어지면 주소가 바뀌고, 복제본을 늘리면 주소가 여러 개가 됩니다.

상황	파드 주소
파드가 다시 시작	바뀝니다
새 버전 배포	전부 바뀝니다
복제본 3개	주소가 3개
노드 이동	바뀝니다

그래서 파드를 주소로 직접 부르면 안 됩니다. 부르는 쪽이 매번 주소를 알아내야 하고, 여러 개일 때 어디로 보낼지도 정해야 합니다.

Kubernetes 는 이 문제를 Service 로 해결합니다.

네트워크 자원 관계

Service 란

파드 묶음에 고정된 이름과 주소를 주는 자원 입니다.

Service 를 만들면 세 가지가 생깁니다.

생기는 것	설명
고정 IP (ClusterIP)	파드가 바뀌어도 이 주소는 그대로입니다
DNS 이름	주소 대신 이름으로 부를 수 있습니다
부하 분산	뒤에 파드가 여럿이면 나눠 보냅니다

부르는 쪽은 Service 이름만 알면 됩니다. 뒤에 파드가 몇 개인지, 어느 노드에 있는지, 지금 막 재시작했는지 신경 쓰지 않아도 됩니다.

DNS 이름 규칙은 이렇습니다.

부르는 위치	쓰는 이름
같은 네임스페이스	`<서비스이름>`
다른 네임스페이스	`<서비스이름>.<네임스페이스>`
전체 이름	`<서비스이름>.<네임스페이스>.svc.cluster.local`

Service 가 파드를 찾는 방법

Service 는 파드를 이름으로 지정하지 않습니다. 레이블(label)로 고릅니다.

이 방식이라 파드가 새로 생기거나 사라져도 Service 설정을 고칠 필요가 없습니다. 레이블만 맞으면 자동으로 대상에 들어갑니다.

반대로, 레이블이 한 글자라도 다르면 연결되지 않습니다. 연결 문제의 절반이 여기서 생깁니다.

Service 유형

유형	접근 범위	쓰는 상황
ClusterIP	클러스터 안에서만	기본값. 내부 서비스끼리 부를 때
NodePort	노드의 특정 포트로 외부에서	임시 확인, 로드밸런서가 없는 환경
LoadBalancer	외부 로드밸런서를 통해	클라우드 환경
ExternalName	외부 주소로 넘김	클러스터 밖 시스템을 이름으로 부를 때

웹 서비스는 보통 ClusterIP + Ingress 조합을 씁니다.

NodePort 는 30000~32767 범위의 포트를 씁니다. 포트 번호를 외워야 하고 노드 주소가 바뀌면 접속 주소도 바뀌므로, 임시 확인 외에는 권하지 않습니다.

Service 목록

네트워킹 > 서비스 로 들어갑니다.

열	설명
이름	Service 이름. 클러스터 안에서 이 이름으로 부릅니다
네임스페이스	속한 네임스페이스
유형	노출 방식
클러스터 IP	클러스터 내부 주소
포트	받는 포트와 전달할 포트

Service 상세

이름을 누르면 상세 화면이 열립니다.

항목	무엇을 확인하는가
선택 조건(Selector)	어떤 레이블의 파드로 보낼지. 파드 레이블과 정확히 같아야 합니다
포트	받는 포트(port)와 파드의 포트(targetPort)
엔드포인트	실제로 연결된 파드 주소 목록

포트가 두 개인 이유 를 알아 두면 편합니다.

이름	뜻
port	Service 가 받는 포트. 부르는 쪽이 쓰는 번호
targetPort	파드가 실제로 여는 포트

둘을 다르게 둘 수 있습니다. 예를 들어 밖에서는 80 으로 부르지만 애플리케이션은 8080 을 여는 경우입니다. targetPort 가 컨테이너의 실제 포트와 다르면 연결되지 않습니다.

엔드포인트가 비어 있으면 트래픽이 갈 곳이 없습니다. 이때는 선택 조건과 파드 레이블을 비교하십시오(3.1 장의 파드 상세).

Endpoint 란

Service 가 실제로 트래픽을 보내는 파드 주소 목록 입니다. Kubernetes 가 자동으로 만들고 관리합니다.

네트워킹 > 엔드포인트 에서 따로 볼 수도 있습니다.

파드가 준비 상태(Ready)가 아니면 엔드포인트에서 빠집니다. 이것이 무중단 배포의 핵심 장치입니다. 새 파드가 아직 준비되지 않았으면 트래픽을 받지 않고, 준비되면 그때 목록에 들어갑니다.

준비 상태를 판단하는 것은 준비 상태 검사(readiness probe) 입니다(3.1 장).

상황	엔드포인트
파드가 준비 상태	들어갑니다
준비 상태 검사 실패 중	빠집니다
파드가 지워지는 중	빠집니다
준비 상태 검사가 아예 없음	컨테이너가 시작되면 바로 들어갑니다

파드가 떠 있는데 엔드포인트에 없다면 준비 상태 검사에 실패하고 있는 것 입니다. 파드 상세에서 검사 경로와 포트가 맞는지 확인하십시오.

반대로 준비 상태 검사가 없으면 컨테이너가 시작되자마자 트래픽이 들어옵니다. 애플리케이션이 아직 뜨는 중이면 그 요청은 실패합니다. 배포할 때마다 잠깐씩 오류가 난다면 이 경우를 의심하십시오.

Ingress 란

외부에서 들어오는 HTTP 요청을 내부 Service 로 연결하는 규칙 입니다.

Service 만으로도 외부 노출은 가능하지만(NodePort, LoadBalancer) 한계가 있습니다.

문제	Ingress 가 해결하는 방법
서비스마다 포트나 로드밸런서가 필요	하나의 진입점을 여럿이 나눠 씁니다
도메인 이름으로 구분할 수 없음	호스트별로 다른 Service 로 보냅니다
경로별로 나눌 수 없음	`/api` 와 `/web` 을 다른 Service 로 보냅니다
HTTPS 를 서비스마다 설정	Ingress 에서 한 번에 처리합니다

Ingress 와 Service 의 차이

	Service	Ingress
다루는 계층	TCP/UDP 포트	HTTP 요청 (호스트·경로)
판단 기준	포트 번호	도메인 이름과 URL 경로
HTTPS 처리	하지 않음	인증서를 붙여 처리
필요한 것	없음	Ingress 컨트롤러가 설치되어 있어야 합니다

Ingress 는 규칙일 뿐입니다. 실제로 트래픽을 처리하는 것은 클러스터에 설치된 Ingress 컨트롤러 입니다. 컨트롤러가 없으면 Ingress 를 만들어도 아무 일도 일어나지 않습니다.

COP 는 HAProxy Ingress Controller 를 설치합니다. 클래스 이름은 default 이고, 클러스터 전체가 이 컨트롤러 하나를 함께 씁니다.

COP 의 Ingress 컨트롤러 기본 설정

설치할 때 정해지는 값입니다. Ingress 를 만들 때 그대로 적용되므로 알아 두면 문제를 빨리 좁힐 수 있습니다.

항목	값	뜻
클래스 이름	`default`	Ingress 의 `ingressClassName` 에 적는 값
클러스터 기본값	예	`ingressClassName` 을 안 적어도 이 컨트롤러가 처리합니다
배치 방식	모든 노드에 하나씩	어느 노드 주소로 들어와도 받습니다
받는 포트	80 · 443	노드의 포트를 직접 씁니다
기본 인증서	`kube-system` 의 `wildcard-tls`	Ingress 에 TLS 를 안 적어도 HTTPS 가 됩니다
HTTPS 리다이렉트	켜짐 (443 으로)	아래 "HTTP 로 접속하게 두려면" 참고
`X-Forwarded-For`	켜짐	아래 "접속한 사용자의 주소 알기" 참고
`X-Forwarded-Proto`	`https` 로 고정	같은 절 참고
헤더 버퍼 크기	16KB	아래 참고

알아 두면 좋은 것 넷

Ingress 에 TLS 를 적지 않아도 HTTPS 가 됩니다. 기본 인증서(wildcard-tls)가 설정되어 있어 spec.tls 를 생략해도 HTTPS 접속이 열립니다. 다만 그 인증서가 보장하는 주소 범위를 벗어나면 브라우저가 경고를 냅니다. 별도 도메인을 쓴다면 인증서를 따로 발급받아 spec.tls 에 적으십시오(7.3 장).

ingressClassName 을 안 적어도 동작합니다. 클러스터 기본 클래스로 지정되어 있기 때문입니다. 그래도 적는 편을 권합니다 — 나중에 컨트롤러가 늘어나면 안 적은 Ingress 가 어디로 갈지 알 수 없게 됩니다.

컨트롤러가 모든 노드에 하나씩 떠 있습니다. 어느 노드 주소로 들어와도 같은 규칙이 적용됩니다. 노드 하나가 내려가도 다른 노드로 들어오면 서비스가 이어집니다.

응답 헤더가 크면 502 오류가 납니다. 헤더를 담는 버퍼가 16KB 입니다. 긴 인증 토큰을 쿠키에 담는 애플리케이션에서 이 한도를 넘는 일이 생깁니다. 파드는 정상인데 브라우저에만 502 가 보이면 이 경우를 의심하고 운영 담당자에게 문의하십시오. 이 값은 Ingress 단위로 바꿀 수 없고 클러스터 전체 설정입니다.

Ingress 목록

네트워킹 > 인그레스 로 들어갑니다.

열	설명
이름	Ingress 이름
클래스	처리할 Ingress 컨트롤러
호스트	외부 접속 주소
경로	주소 뒤 경로별 연결 규칙

IngressClass 는 여러 컨트롤러를 쓸 때 어느 것이 처리할지 정하는 이름표입니다. COP 는 default 하나만 쓰며 기본값으로 지정되어 있어 따로 넣지 않아도 됩니다.

Ingress 상세

항목	설명
규칙	호스트와 경로별로 어느 Service 의 어느 포트로 보내는지
TLS	HTTPS 에 쓸 인증서(Secret) 이름
주석	컨트롤러 동작을 조절하는 설정

주석에 중요한 설정이 들어갑니다. COP 의 HAProxy 컨트롤러는 haproxy.org/ 로 시작하는 이름을 씁니다. 대표적인 것은 이렇습니다.

주석	하는 일
`haproxy.org/path-rewrite`	`/api/users` 로 들어온 요청을 `/users` 로 바꿔 보냅니다
`haproxy.org/ssl-redirect`	HTTP 로 오면 HTTPS 로 돌립니다 (아래 참고)
`haproxy.org/route-acl`	조건에 맞는 요청만 이 Service 로 보냅니다. 카나리 배포에 씁니다(4.8 장)
`haproxy.org/timeout-server`	응답이 느린 서비스의 제한 시간을 늘립니다
`haproxy.org/load-balance`	뒤에 있는 파드에 요청을 나누는 방식을 정합니다

인증서 발급은 7.3 장을 보십시오. TLS 에 지정한 Secret 이 없으면 HTTPS 접속이 실패합니다.

HTTP 로 접속하게 두려면

COP 는 HTTPS 리다이렉트를 클러스터 전체에 켜 둡니다. HTTP 로 들어온 요청을 모두 HTTPS 로 돌립니다. 대부분의 경우 이것이 맞지만, 특정 서비스만 HTTP 로 받아야 할 때가 있습니다.

이럴 때	설명
내부 전용 API	클러스터 안에서만 부르는데 인증서를 붙이기 번거로울 때
HTTPS 를 다루지 못하는 오래된 클라이언트	리다이렉트를 따라가지 못하는 프로그램
앞단에서 이미 HTTPS 를 끝낸 경우	별도 장비가 암호화를 처리하고 뒤로는 평문으로 보낼 때

해당 Ingress 에만 주석을 붙이면 됩니다. 다른 Ingress 는 그대로 리다이렉트됩니다.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: internal-api
  namespace: my-app
  annotations:
    haproxy.org/ssl-redirect: "false"    # 이 Ingress 만 HTTP 허용
spec:
  ingressClassName: default
  rules:
    - host: internal-api.apps.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: internal-api
                port:
                  number: 8080

관련 주석이 셋 있고 모두 Ingress 에 붙일 수 있습니다.

주석	하는 일	값
`haproxy.org/ssl-redirect`	리다이렉트 켜기·끄기	`"true"` · `"false"`
`haproxy.org/ssl-redirect-port`	돌려보낼 포트	기본 `443`
`haproxy.org/ssl-redirect-code`	응답 코드	`301` · `302`(기본) · `303`

값을 따옴표로 감싸십시오. 주석 값은 문자열이라 false 를 따옴표 없이 쓰면 적용할 때 거부됩니다.

spec.tls 를 함께 지우십시오. TLS 구간이 있는 Ingress 는 주석이 없어도 리다이렉트가 켜집니다. HTTP 로만 받으려면 tls 항목을 빼고 주석도 "false" 로 둡니다.

HTTP 는 내용이 암호화되지 않습니다. 로그인 정보나 개인 정보를 주고받는 서비스에는 쓰지 마십시오. 내부망이라도 같은 망 안에서는 내용이 그대로 보입니다.

접속한 사용자의 주소 알기 (X-Forwarded-For)

애플리케이션이 보는 접속 주소는 실제 사용자의 주소가 아닙니다. 요청이 Ingress 컨트롤러를 거쳐 오기 때문에, 애플리케이션 입장에서 접속해 온 것은 컨트롤러 입니다.

그래서 접속 기록을 남기거나, 주소로 접근을 제한하거나, 지역을 판단하는 기능이 전부 같은 주소만 보게 됩니다.

해결책이 X-Forwarded-For 헤더입니다. 컨트롤러가 요청을 넘길 때 원래 사용자의 주소를 헤더에 적어 줍니다. 애플리케이션은 접속 주소 대신 이 헤더를 읽습니다.

COP 의 기본 설정

따로 설정하지 않아도 켜져 있습니다. 모든 Ingress 에 적용됩니다.

헤더	담기는 값	상태
`X-Forwarded-For`	사용자의 실제 주소	켜짐
`X-Forwarded-Proto`	사용자가 쓴 방식 (`https`)	켜짐

X-Forwarded-Proto 도 함께 알아 두면 좋습니다. 컨트롤러가 HTTPS 를 받아 파드에는 HTTP 로 넘기므로, 애플리케이션이 접속 방식만 보면 HTTP 로 착각합니다. 이 헤더를 읽어야 사용자가 HTTPS 로 접속했다는 것을 압니다.

COP 가 이 값을 https 로 고정해 둔 이유가 있습니다. 로그인 뒤 원래 화면으로 돌려보내는 기능이 이 값으로 주소를 만듭니다. 값이 없으면 http:// 로 시작하는 주소를 만들어 보내고, 브라우저가 다시 HTTPS 로 돌아오면서 로그인 정보가 사라집니다. SSO 로그인이 무한히 되풀이되는 증상 이 대표적입니다(1.1 장).

애플리케이션에서 읽는 법

프레임워크마다 이 헤더를 읽는 설정이 따로 있습니다. 읽도록 켜 두어야 접속 주소 대신 이 값을 씁니다.

프레임워크	설정
Spring Boot	`server.forward-headers-strategy=NATIVE`
Tomcat	`RemoteIpValve` 를 서버 설정에 추가
Node.js (Express)	`app.set('trust proxy', true)`
Nginx (컨테이너 안)	`set_real_ip_from` · `real_ip_header X-Forwarded-For`

값이 여럿일 수 있습니다

X-Forwarded-For 는 거쳐 온 순서대로 이어 붙습니다. 앞단에 다른 장비가 있으면 값이 여럿이 됩니다.

X-Forwarded-For: 203.0.113.5, 198.51.100.20
                 ↑ 실제 사용자      ↑ 중간 장비

맨 앞이 실제 사용자입니다. 대부분의 프레임워크가 알아서 처리하지만, 직접 읽는다면 첫 번째 값을 쓰십시오.

이 값을 보안 판단에 그대로 쓰지 마십시오. 헤더는 사용자가 임의로 넣어 보낼 수 있습니다. 접근 제한이나 인증에 쓰려면 컨트롤러 앞단에서 이 헤더를 지우고 다시 채우도록 구성해야 하며, 이는 운영 담당자와 상의할 사항입니다. 접속 기록이나 통계 용도는 문제없습니다.

끄고 싶을 때

거의 없지만, 필요하면 Ingress 나 Service 에 주석으로 끕니다.

metadata:
  annotations:
    haproxy.org/forwarded-for: "false"

네트워크 정책이란

기본 설정에서는 클러스터 안의 모든 파드가 서로 통신할 수 있습니다. 네임스페이스가 달라도 막히지 않습니다.

네트워크 정책은 이것을 제한합니다. "이 파드는 이런 파드에서 오는 요청만 받는다" 를 정합니다.

네트워킹 > 네트워크 정책 에서 봅니다.

방향	설명
Ingress	들어오는 트래픽 허용 규칙
Egress	나가는 트래픽 허용 규칙

허용 대상은 세 가지로 지정합니다.

방식	설명
파드 레이블	특정 레이블을 가진 파드
네임스페이스 레이블	특정 네임스페이스의 모든 파드
IP 대역	클러스터 밖의 주소 범위

만들기 — YAML

Service

apiVersion: v1
kind: Service
metadata:
  name: my-app
  namespace: my-app
spec:
  type: ClusterIP
  selector:
    app: my-app          # 이 레이블을 가진 파드로 보냅니다
  ports:
    - name: http
      port: 80           # Service 를 부를 때 쓰는 포트
      targetPort: 8080   # 컨테이너가 실제로 여는 포트
      protocol: TCP

항목	설명
`selector`	파드의 레이블과 정확히 같아야 합니다. 하나라도 다르면 대상이 0개가 됩니다
`port`	다른 파드가 `http://my-app:80` 처럼 부를 때 쓰는 번호
`targetPort`	컨테이너가 실제로 듣는 번호. 이름으로도 쓸 수 있습니다

port 와 targetPort 를 헷갈리기 쉽습니다. 둘이 뒤바뀌면 Service 는 정상으로 보이는데 연결만 되지 않습니다. Endpoint 화면에 파드는 잡혀 있으므로 원인을 찾기 어렵습니다.

Ingress

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app
  namespace: my-app
spec:
  ingressClassName: default        # COP 기본값 — HAProxy 컨트롤러가 처리합니다
  tls:
    - hosts:
        - app.example.com
      secretName: app-tls-secret      # 인증서를 담은 Secret ([7.3 장](/docs/cop-user-guide/cert-manager))
  rules:
    - host: app.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: my-app          # 위에서 만든 Service 이름
                port:
                  number: 80          # Service 의 port (targetPort 아님)

항목	설명
`ingressClassName`	어느 Ingress 컨트롤러가 처리할지. COP 는 `default` 입니다
`pathType`	`Prefix` 는 그 경로로 시작하는 것 전부, `Exact` 는 정확히 일치
`backend.service.port.number`	Service 의 `port` 를 적습니다. 컨테이너 포트가 아닙니다

경로별로 다른 서비스에 보낼 수 있습니다.

          paths:
            - path: /api
              pathType: Prefix
              backend:
                service:
                  name: api-service
                  port:
                    number: 8080
            - path: /
              pathType: Prefix
              backend:
                service:
                  name: web-service
                  port:
                    number: 80

긴 경로를 먼저 적으십시오. / 를 먼저 적으면 /api 요청도 그쪽으로 갈 수 있습니다.

네트워크 정책

가장 먼저 만들 것은 DNS 를 여는 정책입니다. 아래 "함정" 에서 설명하듯 정책을 하나라도 넣으면 그 파드는 허용 목록 방식으로 바뀌므로, DNS 를 열어 두지 않으면 이름으로 부르는 모든 통신이 끊깁니다.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns
  namespace: my-app
spec:
  podSelector: {}                     # 이 네임스페이스의 모든 파드
  policyTypes:
    - Egress
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
      ports:
        - protocol: UDP
          port: 53
        - protocol: TCP
          port: 53

podSelector: {} 는 비어 있는 것이 맞습니다. "조건 없음" 이므로 그 네임스페이스의 모든 파드가 대상입니다.

그 다음 실제로 필요한 통신을 엽니다. 아래는 web 레이블을 가진 파드만 my-app 의 8080 포트로 들어오게 하는 예입니다.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-web-to-app
  namespace: my-app
spec:
  podSelector:
    matchLabels:
      app: my-app                     # 보호할 대상
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: web                # 같은 네임스페이스의 web 파드
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: frontend   # frontend 네임스페이스 전체
      ports:
        - protocol: TCP
          port: 8080

from 목록의 항목은 "또는" 입니다. 위 예는 web 파드 또는 frontend 네임스페이스에서 오는 요청을 받습니다.

한 항목 안에 두 조건을 같이 쓰면 "그리고" 가 됩니다. 아래는 frontend 네임스페이스의 web 파드만 허용합니다 — 목록 기호(-)의 위치가 다른 것을 눈여겨보십시오.

      from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: frontend
          podSelector:                # 같은 항목 안 — 둘 다 만족해야 합니다
            matchLabels:
              app: web

이 차이는 YAML 상 기호 하나 인데 결과가 크게 다릅니다. 의도보다 넓게 열리거나 아무것도 통과하지 못하게 됩니다.

정책을 넣기 전에

먼저 DNS 정책을 넣습니다.
대상 파드 하나에만 정책을 걸어 봅니다(podSelector 를 좁게).
통신이 되는지 확인한 뒤 범위를 넓힙니다.
되돌릴 수 있게 정책 YAML 을 보관해 둡니다.

네트워크 정책의 함정

한 파드에 정책이 하나라도 걸리면, 그 정책에서 허용하지 않은 트래픽은 모두 막힙니다.

정책이 없을 때는 전부 허용이지만, 하나라도 생기는 순간 허용 목록 방식 으로 바뀝니다. 이것을 모르면 정책 하나를 넣고 서비스가 통째로 끊기는 일이 생깁니다.

정책을 새로 넣은 뒤 통신이 끊기면 다음을 빠뜨렸는지 확인하십시오.

빠뜨리기 쉬운 것	설명
DNS 조회	`kube-system` 네임스페이스의 53 포트. 막히면 이름으로 부르는 모든 통신이 실패합니다
상태 검사	kubelet 이 노드에서 보내므로 파드 레이블로는 잡히지 않습니다
모니터링 수집	지표 수집기가 파드에 접근해야 합니다
나가는 방향	Ingress 만 열고 Egress 를 잊으면 외부 API 호출이 막힙니다

연결이 안 될 때 확인 순서

순서대로 확인하면 대부분 여기서 원인이 나옵니다.

순서	확인할 것	어디에서
1	파드가 `Running` 이고 준비 상태인가	워크로드 > Pod (3.1 장)
2	Service 의 엔드포인트가 비어 있지 않은가	Service 상세
3	Service 의 targetPort 와 컨테이너 포트가 같은가	Service 상세, 파드 상세
4	Ingress 의 호스트·경로가 요청과 맞는가	Ingress 상세
5	네트워크 정책이 막고 있지 않은가	네트워크 정책
6	HTTPS 라면 인증서가 준비되었는가	인증서 관리 (7.3 장)

2번에서 막히는 경우가 가장 많습니다. Service 의 선택 조건과 파드 레이블이 한 글자라도 다르면 연결되지 않습니다.

파드 안에서 직접 확인하려면 웹 터미널에서 다른 서비스를 불러 보십시오(3.1 장). 이름으로 안 되는데 IP 로 되면 DNS 문제이고, 둘 다 안 되면 네트워크 정책이나 포트 문제입니다.

어떨 때 보는가​

파드 주소는 왜 문제인가​

네트워크 자원 관계​

Service 란​

Service 가 파드를 찾는 방법​

Service 유형​

Service 목록​

Service 상세​

Endpoint 란​

Ingress 란​

Ingress 와 Service 의 차이​

COP 의 Ingress 컨트롤러 기본 설정​

알아 두면 좋은 것 넷​

Ingress 목록​

Ingress 상세​

HTTP 로 접속하게 두려면​

접속한 사용자의 주소 알기 (X-Forwarded-For)​

COP 의 기본 설정​

애플리케이션에서 읽는 법​

값이 여럿일 수 있습니다​

끄고 싶을 때​

네트워크 정책이란​

만들기 — YAML​

Service​

Ingress​

네트워크 정책​

정책을 넣기 전에​

네트워크 정책의 함정​

연결이 안 될 때 확인 순서​