Skip to content

Latest commit

 

History

History
246 lines (189 loc) · 10.4 KB

03_What_is_Ingress.md

File metadata and controls

246 lines (189 loc) · 10.4 KB

What is Ingress?

Kubernetes의 Ingress에 대해 알아보아요

Reference: Kubernetes docs



인그레스 (Ingress)


  • 일반적으로 Network traffic은 ingress 와 engress 로 구분된다
    • Ingress는 외부로부터 서버 내부로 유입되는 network traffic
    • Engress는 서버 내부에서 외부로 나가는 network traffic
  • Cluster 내의 서비스에 대한 외부 접근을 관리하는 API Object
    • 일반적으로 HTTPS 를 관리한다
  • Ingress는 부하 분산, SSL 종료, 명칭 기반의 가상 호스팅 을 제공할 수 있다

Terms

  • Node
    • Cluster의 일부
    • Kubernetes에 속한 worker machine
  • Cluster
    • Kubernetes에서 관리되는 container화 된 application을 실행하는 node의 집합
      • 대부분의 Kubernetes 배포에서 cluster에 속한 node는 Public Internet의 일부가 아니다
  • Edge Router
  • Cluster에 방화벽 정책을 적용하는 router
    • Cloud provider or physical hardware의 일부에서 관리하는 Gateway 일 수 있다
  • Cluster Network
    • Kubernetes networking model에 따라 cluster 내부에서 통신을 용이하게 하는 논리적 또는 물리적 링크의 집합
  • Service
    • Label selecter를 사용해서 pod 집합을 식별하는 Kubernetes service
      • 달리 언급하지 않으면 service는 Cluster network 내에서만 routing 가능한 가상 IP를 가지고 있다고 가정한다

What is Ingress?

  • Cluster 외부에서 cluster 내부 서비스로 HTTP 와 HTTPS 경로를 노출한다
  • Traffic routing 은 Ingress resource에 정의된 규칙에 의해 control 된다

image-20200929010831268

  • Ingress는 외부에서 service로 접속 가능한 URL, Load balance traffic, SSL/TSL 종료, 그리고 이름 기반의 virtual hosting service를 제공하도록 구성할 수 있다
    • Ingress controller 는 일반적으로 load balancer를 사용해서 ingress를 수행할 책임이 있으며, traffic을 처리하는데 도움이 되도록 edge router 나 additional frontend 를 구성할 수 있다
  • Ingress는 임의의 port 또는 protocol 을 노출시키지 않는다
    • HTTP와 HTTPS 이외의 service를 인터넷에 노출하려면 일반적으로 Service.Type=NodePort 또는 Service.Type=LoadBalancer를 사용한다

Prerequisites

  • Ingress Controller 가 있어야 Ingress 를 충족할 수 있다
    • Resource만 생성하는 것은 효과가 없다! controller 가 필요하다
  • ingress-nginx 같은 ingress controller 를 배포해야 하는데, ingress controller의 종류는 다양하다

The Ingress resource

A minimal Ingress resource example

# service/networking/minimal-ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: minimal-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - http:
      paths:
      - path: /testpath
        pathType: Prefix
        backend:
          service:
            name: test
            port:
              number: 80

  • 다른 모든 Kubernetes resource와 마찬가지로 ingress에는 apiVersion, kind, metadata field가 필요하다

  • Ingress object의 이름은 유효안 DNS subdomain name 이어야 한다

  • Ingress는 종종 annotation을 이용해서 ingress controller에 따라 몇 가지 option을 구성하는데, rewrite-target annotation 을 예로 들 수 있다

  • 서로 다른 ingress controller는 각각 다른 annotation을 지원한다

  • Ingress spec 에는 Load Balancer 또는 proxy server를 구성하는데 필요한 모든 정보가 있다

    • 가장 중요한 것은, 들어오는 request와 일치하는 규칙 목록을 포함하는 것이다
      • Ingress resource는 HTTP(S) traffic 을 지시하는 규칙만 지원한다

Ingress rules

: 각 HTTP 규칙에는 다음의 정보가 포함된다

  • 선택적 host
    • 만약 host가 제공되면, 규칙이 해당 host에 적용된다
  • 경로 목록
    • 경로 목록에는 각각 service.name, service.port.name or service.port.number 가 정의되어 있는, 관련 backend를 가지고 있다
      • Load balancer가 traffic이 참조된 서비스로 보내기 전에 host와 path 는 incoming request와 내용이 match 되어야 한다
  • Backend
    • Backend는 service docs 또는 사용자 정의 resource backend에 설명된 것 처럼 service 와 port 이름의 조합이다.
      • Host와 규칙 경로가 일치하는 ingress에 대한 HTTP(S) 요청은 backend 목록으로 전송된다

DefaultBackend

  • 규칙이 없는 ingress는 모든 traffic을 하나의 default backend로 전송한다
  • DefaultBackend는 ingress controller 의 구성 option이고, ingress resource 에 지정되어 있지 않다
  • 만약 ingress object 의 HTTP 요청과 일치하는 host or path가 없으면, traffic은 default backend로 routing 된다

Resource Backend

  • Resource backend 는 ingresss object의 동일한 namespace 내에 있는 다른 Kubernets resource에 대한 ObjectRef 이다
  • Resource 는 service와 상호 배타적인 설정이며, 둘 다 지정하게 되면 유효성 검사 를 통과 할 수 없다
    • 유효성 검사에 실패한다
  • Resource backend 의 일반적인 용도는 static asset이 있는 object storage backend로 data를 수신하는 것 이다

Resource backend example

# service/networking/ingress-resource-backend.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-resource-backend
spec:
  defaultBackend:
    resource:
      apiGroup: k8s.example.com
      kind: StorageBucket
      name: static-assets
  rules:
    - http:
        paths:
          - path: /icons
            pathType: ImplementationSpecific
            backend:
              resource:
                apiGroup: k8s.example.com
                kind: StorageBucket
                name: icon-assets

  • 위의 yaml file 처럼 ingress 를 생성하고, 아래의 명령으로 생성된 ingress를 확인 할 수 있다

    $ kubectl describe ingress ingress-resource-backend

    • 결과

      Name:             ingress-resource-backend
Namespace:        default
Address:
Default backend:  APIGroup: k8s.example.com, Kind: StorageBucket, Name: static-assets
Rules:
  Host        Path  Backends
  ----        ----  --------
  *
              /icons   APIGroup: k8s.example.com, Kind: StorageBucket, Name: icon-assets
Annotations:  <none>
Events:       <none>

Path types

  • Ingress 의 각 경로에는 해당 경로의 유형이 있어야 한다
    • 명시적 pathType 을 포함하지 않는 경로는 유효성 검사 를 통과하지 못한다!
  • 지원되는 경로 유형은 아래의 3가지가 있다
    1. ImplementationSpecific
      • 이 경로 유형의 일치 여부는 IngressClass 에 따라 달라진다
        • 이것을 구현할 때 별도 pathType 으로 처리하거나,
        • Prefix 또는 Exact 경로 유형처럼 처리할 수 있다
    2. Exact
      • URL 경로의 대소문자를 엄격하게 일치시킨다
    3. Prefix
      • URL 경로의 접두사를 / 를 기준으로 분리한 값과 일치시킨다
        • 대소문자를 구분하고,
        • Element basis로 path element를 일치시킨다
      • Request path의 모든 element별 접두사가 p 인 경우 요청은 p 경로에 일치하는 것이다
        • 단, 경로의 마지막 요소가 request path에 있는 마지막 element의 하위 문자열인 경우에는 일치하지 않는다
          • ex)
            • /foo/bar 와 /foo/bar/baz 는 일치하지만,
            • /foo/bar 와 /foo/barbaz 는 일치하지 않는다!

Examples

종류 경로 요청 경�로 일치 여부
Prefix / (모든 경로) 예
Exact /foo /foo 예
Exact /foo /bar 아니오
Exact /foo /foo/ 아니오
Exact /foo/ /foo 아니오
Prefix /foo /foo, /foo/ 예
Prefix /foo/ /foo, /foo/ 예
Prefix /aaa/bb /aaa/bbb 아니오
Prefix /aaa/bbb /aaa/bbb 예
Prefix /aaa/bbb/ /aaa/bbb 예, 마지막 슬래시 무시함
Prefix /aaa/bbb /aaa/bbb/ 예, 마지막 슬래시 일치함
Prefix /aaa/bbb /aaa/bbb/ccc 예, 하위 경로 일치함
Prefix /aaa/bbb /aaa/bbbxyz 아니오, 문자열 접두사 일치하지 않음
Prefix /, /aaa /aaa/ccc 예, /aaa 접두사 일치함
Prefix /, /aaa, /aaa/bbb /aaa/bbb 예, /aaa/bbb 접두사 일치함
Prefix /, /aaa, /aaa/bbb /ccc 예, / 접두사 일치함
Prefix /aaa /ccc 아니오, 기본 백엔드 사용함
Mixed /foo (Prefix), /foo (Exact) /foo 예, Exact 선호함

Multiple matches

  • 경우에 따라 Ingress의 여러 경로가 request와 일치할 수 있다
    • 이 경우 일치하는 경로 중 가장 긴 경로가 우선순위를 갖는다
      • 두 개의 경로의 길이가 동일한 경우, Prefix 경로 유형보다 Exact 경로 유형을 가진 경로가 사용된다!


+

  • Kubernetes의 서비스는 L4 layer 로 TCP단에서 Pods 를 balancing 한다