[Kubernetes] NetworkPolicy, Ingress

 

 

 

같은 클러스터 안에서 Pod 끼리는 서로 자유롭게 통신할 수 있다. 

다만 이러면 해킹당한 Pod이 다른 Pod에 마음대로 접근할 수 있어서 보안상 위험하다. 

 

그러니 누가 누구랑 통신할 수 있는지를 제한하는게 NetworkPolicy이다. 네트워크 수준에서의 방화벽임.

 

NetworkPolicy가 없다면 기본적으로 전부 허용하고, NetworkPolicy가 Pod에 적용되면 그 Pod는 명시한 것만 허용하고 나머지는 차단한다.

RBAC랑 비슷함. 

 

AWS처럼 Ingress와 Egress를 정의해야 함. 다만 Ingress를 잘 다루는게 더 중요하다. 

Label Selector로 Pod를 고르고.. 

 

YAML 적을 때는 그냥 k8s docs 그대로 가져다 쓰면 된다. 아무도 외워서 안씀.

템플릿 가져와서 필요한 부분만 수정하자. 

 

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: db-policy
  namespace: ts
spec:
  podSelector:              # 이 정책을 적용할 Pod (라벨로)
    matchLabels:
      app: db
  policyTypes:
  - Ingress                 # 들어오는 트래픽 제어
  ingress:
  - from:                   # 누가 들어올 수 있나
    - podSelector:
        matchLabels:
          app: backend      # backend 라벨 Pod만 허용
    ports:
    - protocol: TCP
      port: 5432            # 5432 포트로만

 

 

podSelector: {} 로 비워두면 namespace의 모든 Pod를 이 정책의 대상으로 설정하고, 거기에 ingress 규칙을 작성하지 않으면 전부 차단하는 패턴을 구현할 수 있다. 

 

허용 대상을 설정하는 from 에는 두 종류가 있다.

podSelector로 특정 라벨의 Pod를 허용할 수 있고, namespaceSelector로 특정 namespace에서 오는 요청을 허용할 수 있음. 

 

minikube는 NetworkPolicy를 강제하지 않으니 YAML 작성 연습으로만.. 

 

DB는 백엔드만 접속하면 되고.. 프론트엔드가 DB에 직접 붙을 이유가 없다.

기본 상태면 프론트도 DB에 접속할 수 있고 해킹당한 Pod도 DB에 접속할 수 있으니 NetworkPolicy를 걸어준다. 

 

 

---

 

 

 

NetworkPolicy 에서의 Ingress는 들어오는 트래픽을 의미하지만 리소스에서의 Ingress는 외부에서 클러스터로 들어오는 HTTP 트래픽을 라우팅하는 역할을 수행한다. 

 

외부에서 앱에 접속하려면 Service를 NodePort나 LoadBalancer로 여는데 앱이 여러 개면 문제가 생김.

서비스마다 NodePort를 따로 열어야 하고 LoadBalancer를 쓰면 LB마다 과금되니 비용도 늘어난다. 

 

이 때 Ingress를 사용해서 입구 하나로 여러 서비스에 트래픽을 분산시킨다. 

AWS ALB랑 똑같은 역할을 수행함. 트래픽을 받아서 여러 타겟그룹으로 분배해주는 역할.

실제로 AWS EKS를 쓸 때 Ingress Controller 사용 시 ALB가 자동으로 생성된다. 

 

이거 말고도 AWS에 대응되는 쿠버 개념들이 많다.

 

NetworkPolicy는 Pod 수준에서 적용할 수 있는 SecurityGroup을 의미하고

PVC/PV는 EBS 볼륨을 의미하고 

Node는 EC2 인스턴스를 의미하고 

Service는 ELB/NLB로 L4 로드밸런서를 의미한다.

 

서비스는 4계층의 로드밸런서 역할을 수행하고, Ingress는 7계층의 로드밸런서 역할을 수행한다. 

 

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
  namespace: ts
spec:
  rules:
  - http:
      paths:
      - path: /shop
        pathType: Prefix
        backend:
          service:
            name: shop
            port:
              number: 80
      - path: /blog
        pathType: Prefix
        backend:
          service:
            name: blog
            port:
              number: 80

 

 

Ingress도 YAML은 k8s docs에서 가져와서 필요한거만 수정하자. 

규칙을 실행할 Controller도 함께 설정해 줘야 함. 

 

 

 

---

 

 

 

Ingress는 경로 기반 라우팅만 제공한다. /shop이나 shop.com 이런식으로.. 그러니 카나리 배포나 헤더 기반 라우팅이 힘들다.

그래서 Ingress를 대체하는 차세대 라우팅으로 Gateway API가 도입됐다. 

 

기존에는 Ingress를 한 덩어리로 다뤘지만 이제는 역할별로 세 개로 나눠서 다룬다. GatewayClass + Gateway + HTTPRoute 

 

1. GatewayClass

어떤 종류의 게이트웨이인지 정의한다.

인프라 제공자가 직접 다룬다. nginx cloud LB 등..

관리자가 설정함

 

2. Gateway

실제로 트래픽을 받는 곳으로 포트나 프로토콜을 정의한다. 

80포트 + HTTP | 클러스터 관리자가 만듦

 

3. HTTPRoute

어떤 경로를 어떤 서비스로 보낼지를 결정한다. 

앱 개발자가 만듦

 

역할별로 잘 구분되니 개발자는 인프라를 몰라도 된다.

 

 

1. Gateway
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: my-gateway
spec:
  gatewayClassName: nginx      # 어떤 종류
  listeners:
  - name: http
    port: 80                   # 80포트로 받음
    protocol: HTTP
    
2. HTTPRoute
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: my-route
spec:
  parentRefs:
  - name: my-gateway           # 위 Gateway에 붙음
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /shop           # /shop 경로는
    backendRefs:
    - name: shop               # shop 서비스로
      port: 80