목차
8.1 인그레스의 개념
인그레스(ingress)는 클러스터 외부에서 내부로 접근하는 요청들을 어떻게 처리할지 정의해둔 규칙들의 모음이다.
쉽게 말해, 인그레스는 외부에서 쿠버네티스에서 실행중인 디플로이먼트와 서비스에 접근하기 위한, 일종의 관문(Gateway) 같은 역할을 담당한다.
인그레스는 아래와 같은 기능을 제공한다.
•
외부에서 접근해야 할 URL을 사용
•
트래픽 로드밸런싱
•
SSL 인증서 처리
•
도메인 기반 가상 호스팅 제공
클라우드 서비스를 사용하면 별다른 설정없이 자체 로드밸런서 서비스와 연동해서 인그레스를 사용할 수 있으며, 클라우드 서비스를 사용하지 않고 직접 쿠버네티스 클라이언트를 구축해서 사용한다면 인그레스 컨트롤러를 직접 인그레스와 연동해야 한다. 이때 가장 많이 사용하는 도구는 쿠버네티스에서 제공하는 ingress-nginx이다.
•
인그레스 설정 예시
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: test
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
spec:
rules:
- host: foo.bar.com
http:
paths:
- path: /foos1
pathType: Prefix
backend:
service:
name: s1
port:
number: 80
- path: /bars2
pathType: Prefix
backend:
service:
name: s2
port:
number: 80
- host: bar.foo.com
http:
paths:
- backend:
serviceName: s2
servicePort: 80
YAML
복사
ingress-basic.yaml
주요 설정 부분은 다음과 같다.
1.
인그레스를 설정할 때는 .metadata.annotations의 하위 필드를 사용한다. 하위 필드의 설정은 인그레스 컨트롤러마다 다르다.
위에서는 ingress-nginx 컨트롤러를 사용하므로 nginx.ingress.kubernetes.io/rewrite-target 을 키로 하고 /을 값으로 하는 필드 값을 설정했다. / 경로로 리다이렉트 하라는 뜻.
2.
.spec.rules[] 의 하위 필드에는 어떤 규칙들을 사용할지 지정할 수 있다.
첫 번째 .spec.rules[].host 필드 값은 foo.bar.com이다. foo.bar.com의 주소로 요청이 들어오면 다음에 설정하는 규칙에 따라 처리한다.
.spec.rules[].http.paths[] 의 하위 필드는 HTTP요청이 어떤 경로에서 들어오는지를 뜻한다.
첫 번째 .spec.rules[].http.paths[] 필드 값은 /foos1 경로를 설정했고, 경로의 유형을 결정하는 .pathType 필드 값을 Prefix로 설정했다. 필드 값으로는 Prefix와 Exact를 주로 사용한다.
backend[] 의 하위 필드 값은 foo.bar.com/foos1 으로 오는 요청을 s1이라는 서비스의 80 포트로 보내라는 뜻이다.
두 번째 .spec.rules[].http.paths[] 필드 값은 /bars2 경로를 설정했고, 경로의 유형을 결정하는 .pathType 필드 값을 Prefix로 설정했다. backend[] 의 하위 필드 값 까지 보면, foo.bar.com/bars2 으로 오는 요청은 s2 서비스의 80 포트로 보내라는 뜻이다.
3.
두 번째 .spec.rules[].host 필드 값 설정도 위의 의미들로 해석이 가능하다.
위의 ingress-basic.yaml을 저장 후 kubectl apply -f ingress-basic.yaml 명령어로 클러스터에 적용한다. 그런데, 다음과 같은 오류가 떴다.
찾아본 결과, ingress의 apiVersion이 변경됨에 따라, v1 버전의 yaml 문법이 맞지 않는 것으로 확인되었다. 따라서 두 번째 호스트 필드 값을 다음과 같이 수정 후, 진행하였다.
- host: bar.foo.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: s2
port:
number: 80
YAML
복사
kubectl describe ingress <인그레스 이름> 명령을 실행.
foo.bar.com으로 요청이 오더라도 뒷부분의 경로에 따라서 /foos1 이면 서비스 s1로, /bars2 이면 서비스 s2로 연결되도록 설정되었다. 또다른 호스트네임인 bar.foo.com도 서비스 s2로 연결되었다.
8.2 ingress-nginx 컨트롤러
인그레스는 사실 설정일 뿐이고, 설정 내용대로 동작하는 실제 주체는 인그레스 컨트롤러이다. 컨트롤러는 여러가지가 있지만 쿠버네티스가 공식적으로 제공하는 것은 구글 컴퓨트 엔진용 ingress-gce와 nginx용 ingress-nginx이다.
ingress-gce는 GCE를 이용하면 자동으로 사용할 수 있으므로, ingress-nginx를 알아보자. 먼저 git clone https://github.com/kubernetes/ingress-nginx.git 명령으로 ingress-nginx 깃허브 저장소를 클론한다.
다음은 ingress-nginx/deploy/static/provider/cloud 디렉터리의 deploy.yaml을 실행 후 type: LoadBalancer을 type: NodePort로 변경한다.
kubectl apply -f deploy.yaml 로 적용. 이후 컨트롤러 및 서비스의 상태를 확인한다.
nginx-ingress-controller 디플로이먼트 실행 및 ingress-nginx NodePort타입 서비스 생성을 확인 가능.
PORT(S) 항목의 30528 포트를 이용해 nginx로 만든 웹 서버에 접속하면 다음과 같이 실행된다.
별도의 인그레스 설정이 없을 때는 에러 메시지가 나타난다. 이는 아직 클러스터 외부에서 온 요청을 어떻게 처리할지 규칙을 설정하지 않았기 때문이다.
이제 인그레스 템플릿에서 설정한 foo.bar.com에 접근해보자. 먼저 6장에서 적용했던 nginx-deployment 디플로이먼트를 인그레스에 연결해야 한다. 이는 kubectl expose deploy nginx-deployment --name s1 명령으로 인그레스에 지정했던 s1이라는 이름을 이용한 nginx-deployment 디플로이먼트의 서비스를 만드는 것이다.
다음은 /etc/hosts 파일을 변경하여 foo.bar.com 도메인을 등록해준다.
sudo vi /etc/hosts를 열어 127.0.0.1 foo.bar.com을 hosts 파일 맨 아래에 추가한다.
8.3 인그레스 SSL 설정하기
8.4 무중단 배포를 할 때 주의할 점
•
파드 교체 구조
