ingress/ 설치 & 개념

# 설치

사실 난 이미 다 설치해놨는데 실제로 설치할때 경로찾는게 중요할것 같아서 조금 자세하게 적어볼거다.

k8s공식문서에서 ingress controller를 검색하고 저 링크로 들어간다.

 

 

그리고 저기에 쿠버네티스가 서포트 하고 있따는 aws,gce,nginx중 선택해야하는데

우리는 온프레미스 환경에서 텍스트할거니까 nginx를 선택하자.

 

 

그럼 깃헙 페이지가 뜨고 저기서 getting started를 누르면 

Installation Guide - Ingress-Nginx Controller

가이드 웹사이트로 이동하는데,

contents에서

베어메탈을 선택하면,  

베어메탈 클러스터를 설치할 명령어가 뜬다.

 

마스터 노드에서 

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.8.2/deploy/static/provider/baremetal/deploy.yaml

저기 제공된걸 복붙해서 바로 apply해서 ingress controller를 설치해버리거나,

그냥 저기 github링크를 wget으로 받아서  설치해줘도 된다.

wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.8.2/deploy/static/provider/baremetal/deploy.yaml

kubectl create -f deploy.yaml

파일 받고 kubectl create 명령어로 설치해주면 된다.

 

 

# ingress controller도 k8s환경에서 여러 리소스들로 운영된다.

vi deploy.yaml

wget으로 받은yaml파일을 대충 훝어보면,

 

 

보다싶이 여러 리소스들을 생성해버린다.

이게 바로 ingress controller를 운영하는 리소스들이다.

 

 

# ingress controller가 작동하는건지 확인

kubectl get all --all-namespaces | grep ingress

해당 명령어로 ingress라는 스트링을 포함한 리소스들을 확인해보면, 

뭐 이것저것 ingress리소스들이 보인다.

 

 

 

# 개념

공식문서에서 가져온 사진인데, 인그레스로 클라이언트 요청이 들어오고 이 요청에 따라 서비스를 따로 배치해놓을 수 있다. 내가 직접 그린 그림을 보면,

 

ingress controller가 있고 이곳이 단일진입점이 된다. 외부에서 접속하는것이기때문에 서비스 타입은 NodePort이며, pod는 그림과 달리 다른 노드에도 있을 수 있으나, 이해를 쉽게하기 위해 마스터노드에 그렸다.

여기서 도메인:노드포트/api으로 요청을 할때, 요청하는 api에 따라 서비스를 각각 선택 할 수 있다. /muzzi로 요청이 들어오면, muzzi서비스에 가서 muzzi-deployment로 요청을 보내주고 응답받고, /dori로 요청이 들어오면 dori 서비스에 가서 dori-deployment로 요청을 보내고 받는다.

 

실제로 저렇게 환경을 만들어서 보면, 

pod정보인데 ingress-nginx-controller가 worker1노드에서 running중이고

서비스들을 보면, ingress-nginx-controller가 단일진입점으로 작동하고, dori와 muzzi서비스가 각각 있어서 ingress-nginx-controller로부터 api에 따라 선택받는다.

 

 

# 그럼 worker1노드가 단일진입점이 되는거야? ->아닌듯

난 각각 

master node : 211.183.3.10

worker1 node : 211.183.3.20

worker2 node : 211.183.3.30

으로 클러스터를 구축했는데, 이렇게 dog.com을 호스트로 ingress controller를 구성해서 테스트 해봤다.

맨처음 ingress controller가 /dori요청으로 잘 작동한다. 이 당시에는 dog.com이 worker1 node의 아이피였다.

그다음 worker2노드, master노드 모두 dog.com으로 호스트를 지정해주고 똑같이 테스트해봤으나 모두 작동했다.

즉 모든 노드들에 인그레스 컨트롤러 노드포트로 진입하면 동작한다는거다.

 

 

 

# ingress controller의 여러 기능들.

1. service에 외부 URL제공

난 service와 ingress controller를 연결할때 host로 테스트해봤다. 강의내용처럼 아이피로 접속하는건 안되길래 ㅠ

뭐 이런말같다.

 

2. 트래픽 로드밸런싱

이건 뭐 /muzzi로 요청하거나 /dori로 요청하거나등이 다르니까 로드밸런싱을 해준다는건지,

공식문서 이 그림에서 인그레스,매니지드 로드 밸런서가 인그레스 앞단에서 클라이언트 요청을 받는데, 아까 테스트해봤던것처럼 클러스터를 구성한 각각의 vm들 혹은 인스턴스들에게 각각 로드밸런싱 해준다는건지 잘 모르겠지만 아마 후자같다. 강의내용에선 전자라고했는데.. 후자같음.

 

 

3. SSL인증서 처리

이건 편할것 같다. 요청들어오면 모드 ssl인증서처리해주고 80포트로 넘겨주는데 쓸만할듯. nginx가 웹서버 기반이라 이런건 기똥차게 설정해주니까 매우 편할것같다.

 

 

4. virtual hosting지정

난 도메인을 하나만 설정해서 api요청만 다르게 해서 테스트해봤지만, 실제로는 여러 도메인으로 한 클러스터에서 여러 서비스를 구성 할 수도 있다. ingress.yaml파일 손을 좀 봐야할듯하다.

뭐 도메인 두개를 한 웹사이트 클러스터에 연결한다거나, 도메인 두 개이상을 한 클러스터에 연결한다거나 등등 뭐 여러가지 있을수 있을듯하다.

 

 

 

 

# 왜 ingress controller는 k8s에서 기본적으로 제공해주지 않을까?

ingress는 이전에 배웠던것마냥 단순히 yaml파일만 생성하여 k8s에서 기본적으로 제공해주는 엔진으로 생성되지 않는다.

때문에 우리는 ingress controller를 설치했던 것인데 그 이유를 좀 알고 싶었다.

근데 모르겠으니 gpt한테 물어보았다..

1. 다양성과 확장성: Kubernetes는 다양한 환경에서 사용되며, 각각의 클러스터가 다른 요구 사항을 가집니다. Ingress의 사용 사례와 설정이 클러스터 간에 다르기 때문에 특정 Ingress Controller를 기본으로 제공하는 것은 일반적인 사용 사례를 충족하지 못할 수 있습니다. Kubernetes는 다양한 Ingress Controller 옵션을 허용하여 사용자가 자신의 요구 사항에 맞게 선택할 수 있도록 합니다.
2. 커뮤니티 참여: Kubernetes는 큰 개방형 소스 커뮤니티에 기반하고 있으며, 다양한 Ingress Controller 프로젝트들이 활발하게 개발되고 있습니다. 이러한 다양성은 사용자들이 자신의 환경에 맞게 선택할 수 있도록 하는데 도움이 됩니다. 각 Ingress Controller는 자체적으로 특정 기능, 설정 및 통합을 제공하며, 이는 클러스터의 목적이나 보안 요구 사항에 따라 다를 수 있습니다.
3. 플러그인 아키텍처: Kubernetes는 플러그인 아키텍처를 강조하고 있습니다. 이는 필요에 따라 사용자가 원하는 Ingress Controller를 선택하고 통합할 수 있는 유연성을 제공합니다. 플러그인 아키텍처를 통해 클러스터의 기능을 확장하고 커뮤니티가 다양한 Ingress Controller를 개발하고 공유할 수 있습니다.
4. 코어 기능의 간결성: Kubernetes는 코어 기능을 간결하게 유지하고, 필요에 따라 클러스터를 확장할 수 있는 플러그인 및 확장 기능을 지원하는 것이 중요하게 여겨집니다. 기본적인 기능을 유지하면서 클러스터의 복잡성을 최소화하는 것이 목표입니다.

뭐이렇대