Ingress
인그레스 라우팅 과정
인그레스는 일련의 규칙에 따라 도메인 네임과 애플리케이션의 요청 경로를 매핑해주는 역할을 한다.
인그레스는 리버스 프록시를 인그레스 컨트롤러로 사용하여 외부 트래픽을 받아들이고 ClusterIP 서비스를 통해 실제 요청을 처리한다. 즉, Nginx나 HAProxy, 컨투어 등을 리버스 프록시로 사용할 수 있다.
인그레스 컨트롤러는 파드에서 실행되며 인그레스 객체를 감시하여 변경이 감지되면 해당 규칙을 적용한다.
인그레스 객체에는 라우팅 규칙이 어떤 인그레스 컨트롤러이든 사용 가능한 일반적인 형태로 기술되어 있으며, 인그레스 컨트롤러가 이 규칙을 적용해 프록시 역할을 한다.
인그레스는 클러스터 전체에 영향을 미치며, 인그레스 라우팅 규칙이 여러 개가 존재할 경우 다른 인그레스 컨트롤러에 영향을 미칠 수 있다. 따라서 도메인 이름을 명시해 라우팅 적용 범위를 최대한 제한하는 것이 좋다.
다음은 인그레스 컨트롤러로 nginx를 사용하기 위한 서비스, 디플로이먼트 정의 중 일부이다.
apiVersion: v1
kind: Namespace
metadata:
name: kiamol-ingress-nginx
labels:
kiamol: ch15
---
apiVersion: v1
kind: ConfigMap
metadata:
name: ingress-nginx-controller
namespace: kiamol-ingress-nginx
data:
http-snippet: |
proxy_cache_path /tmp/nginx-cache levels=1:2 keys_zone=static-cache:2m max_size=100m inactive=7d use_temp_path=off;
proxy_cache_key $scheme$proxy_host$request_uri;
proxy_cache_lock on;
proxy_cache_use_stale updating;
---
apiVersion: v1
kind: Service
metadata:
name: ingress-nginx-controller
namespace: kiamol-ingress-nginx
spec:
type: LoadBalancer
ports:
- name: http
port: 80
targetPort: http
- name: https
port: 443
targetPort: https
selector:
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/component: controller
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: ingress-nginx-controller
namespace: kiamol-ingress-nginx
spec:
selector:
matchLabels:
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/component: controller
template:
metadata:
labels:
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/component: controller
spec:
containers:
- name: controller
image: quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.33.0
args:
- /nginx-ingress-controller
- --publish-service=kiamol-ingress-nginx/ingress-nginx-controller
- --election-id=ingress-controller-leader
- --ingress-class=nginx
- --configmap=kiamol-ingress-nginx/ingress-nginx-controller
securityContext:
runAsUser: 101
allowPrivilegeEscalation: true
env:
- name: POD_NAME
valueFrom:
fieldRef:
fieldPath: metadata.name
- name: POD_NAMESPACE
valueFrom:
fieldRef:
fieldPath: metadata.namespace
ports:
- name: http
containerPort: 80
protocol: TCP
- name: https
containerPort: 443
protocol: TCP
serviceAccountName: ingress-nginx다음은 인그레스 컨트롤러에 라우팅 규칙을 전달할 인그레스 객체의 정의이다.
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: hello-kiamol
labels:
kiamol: ch15
spec:
rules:
- http:
paths:
- path: /
backend:
serviceName: hello-kiamol
servicePort: 80인그레스 규칙을 이용한 HTTP 트래픽 라우팅
인그레스는 웹 트래픽인 HTTP/HTTPS 요청만 다룬다.
HTTP 요청에 담긴 라우팅 정보는 크게 호스트와 경로 두 부분으로 나뉜다. 호스트는 도메인 네임(
www.manning.com)이며, 경로는 자원의 구체적 위치 (/dotd)이다.인그레스 객체에서 host 속성을 통해 특정 도메인에 대한 요청에 한해서만 라우팅 규칙을 적용할 수 있다.
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: hello-kiamol
labels:
kiamol: ch15
spec:
rules:
- host: hello.kiamol.local
http:
paths:
- path: /
backend:
serviceName: hello-kiamol
servicePort: 80인그레스를 통해 각 경로에 따라 서로 다른 서비스에 요청을 전달할 수 있다.
컨트롤러로부터 입력받은 URL 대신 다른 URL로 서비스 요청을 보내려면, rewriting 관련 어노테이션에서 정규 표현식을 이용해 요청 경로를 대상 경로로 변환해야 한다.
아래 예제에서는 vweb.kiamol.local 도메인으로 들어온
/,/v1요청을 각각 다른 서비스를 이용해 처리하며, rewrite-target 어노테이션을 이용해 경로를 모두/로 변환한다.
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: vweb
labels:
kiamol: ch15
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
spec:
rules:
- host: vweb.kiamol.local
http:
paths:
- path: /
backend:
serviceName: vweb-v2
servicePort: 80
- path: /v1
backend:
serviceName: vweb-v1
servicePort: 80
- path: /v2
backend:
serviceName: vweb-v2
servicePort: 80인그레스 규칙에 모니터링 지표를 위한 엔드포인트 등 외부로 노출되면 안되는 경로를 정의하지 않는다면 외부로부터의 접근이 차단된다. 하지만 공개하기 위한 경로를 모두 열거해야 하기 때문에 인그레스 정의 파일이 복잡해질 수는 있다.
pathType 속성을 통해 인그레스 경로가 완벽히 일치해야 하는지, 처음 일부만 일치해야 하는지 설정할 수 있다.
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: todo
labels:
kiamol: ch15
spec:
rules:
- host: todo.kiamol.local
http:
paths:
- pathType: Exact
path: /
backend:
serviceName: todo-web
servicePort: 80
- pathType: Prefix
path: /static
backend:
serviceName: todo-web
servicePort: 80인그레스 컨트롤러
인그레스 컨트롤러의 유형은 다음 두 가지가 있다.
리버스 프록시는 네트워크 수준에서 동작하고 호스트네임을 기준으로 콘텐츠를 가져온다.
현대적 프록시는 경량화되었고 플랫폼마다 다르게 동작하며 다른 서비스와 통합이 용이하다.
다양한 기능 제공
인그레스 컨트롤러는 SSL 터미네이션, 방화벽, 캐싱, 단위 시간 당 접근 수 제한, URL rewriting, 허용 클라이언트 IP 목록 등의 기능을 지원한다.
다음은 캐싱을 적용한 인그레스 정의의 예시이다. 캐싱 기능은 인그레스 규격에서 정의된 것이 아니라 지원하지 않는 인그레스 컨트롤러도 있다.
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: pi
labels:
kiamol: ch15
annotations:
nginx.ingress.kubernetes.io/proxy-buffering: "on"
nginx.ingress.kubernetes.io/configuration-snippet: |
proxy_cache static-cache;
proxy_cache_valid 10m;
spec:
rules:
- host: pi.kiamol.local
http:
paths:
- path: /
backend:
serviceName: pi-web
servicePort: 80한 사용자가 보낸 요청들은 동일한 컨테이너로만 전달하는 sticky session 기능역시 인그레스 정의에 추가해 사용할 수 있다.
크로스 사이트 요청 위조 방지 대책으로 인해 데이터의 값을 변경하는 요청들에 한해 서로 다른 파드에 요청이 분배되면 400 Bad Request 응답이 올 수 있다. 따라서 데이터의 값을 변경하는 요청들에 한해 sticky session을 적용해 로드밸런싱을 해제해주어야 한다.
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: todo-new
annotations:
nginx.ingress.kubernetes.io/affinity: cookie
spec:
rules:
- host: todo.kiamol.local
http:
paths:
- pathType: Exact
path: /new
backend:
serviceName: todo-web
servicePort: 80인그레스의 캐싱, Sticky Session 등의 기능은 모든 경로 설정에 적용되기 때문에 서로 다른 기능을 사용하고자 한다면 인그레스를 여러개 두어야 한다.
여러 인그레스 컨트롤러 사용
한 클러스터 안에 여러 개의 인그레스 컨트롤러를 두면 로드밸런서 서비스 형태로 외부에 노출된다. 각 인그레스 컨트롤러들이 각각 IP주소를 갖도록 하고 도메인 네임을 인그레스에 연결할 수 있다.
인그레스 클래스를 이용해 애플리케이션에서 어떤 인그레스 컨트롤러를 사용할 지 정할 수 있다.
apiVersion: v1
kind: Service
metadata:
name: todo-web-sticky
labels:
kiamol: ch15
annotations:
kubernetes.io/ingress.class: traefik
traefik.ingress.kubernetes.io/service.sticky.cookie: "true"
spec:
ports:
- port: 80
targetPort: 80
selector:
app: todo-web
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: todo2-new
labels:
kiamol: ch15
annotations:
kubernetes.io/ingress.class: traefik
traefik.ingress.kubernetes.io/router.pathmatcher: Path
spec:
rules:
- host: todo2.kiamol.local
http:
paths:
- path: /new
backend:
serviceName: todo-web-sticky
servicePort: 80인그레스로 HTTPS 적용
인그레스 컨트롤러에서 HTTPS를 지원하기 위한 TLS 인증서를 비밀값에서 불러올 수 있다. 이를 통해 각 애플리케이션에서 사용할 인증서를 한 곳에서 관리할 수 있다는 장점을 가진다.
kubectl create secret tls <비밀값이름> --key=<key파일> --cert=<crt파일>apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: todo2-new
labels:
kiamol: ch15
annotations:
kubernetes.io/ingress.class: traefik
traefik.ingress.kubernetes.io/router.pathmatcher: Path
traefik.ingress.kubernetes.io/router.tls: "true"
spec:
rules:
- host: todo2.kiamol.local
http:
paths:
- path: /new
backend:
serviceName: todo-web-sticky
servicePort: 80
tls:
- secretName: <비밀값이름>Traefik 인그레스 컨트롤러를 사용하면 Traefik을 배치할 때 생성되는 자체 서명된 인증서를 사용할 수 있으며, 어노테이션에서 TLS와 기본 TLS 리졸버를 활성화할 수 있다. 단, 자체 서명 인증서를 사용하면 브라우저에서 완전히 안전한 상태가 아니라는 경고가 뜬다.
인그레스의 단점
현재는 인그레스 컨트롤러가 제공하는 기능과 어노테이션이 각각 다르기 때문에 여러 인그레스 컨트롤러를 사용할 경우 어려움을 겪을 수 있다.
다양한 배포 전략을 이용한 트래픽 제어 기능을 지원하지 않으며 서비스의 회복 탄력성 관련 기능(retry, circuit breaker 등)이 없다. 이러한 인그레스의 한계점은 Istio를 통해 극복할 수 있다.
Last updated