Day 47 - 쿠버네티스 인그레스

오늘 배운 내용

- 쿠버네티스 인그레스

 

 

쿠버네티스 인그레스

서비스를 외부에 노출할 수 있는 방법

1. NodePort

2. LoadBalancer

3. Ingress (Service Type 아님) ingress는 서비스 위에서 동작한다 (서비스가 있어야지 동작할 수 있다)

 

Ingress는 무슨 메리트가 있는가? 

 

URL - DNS

URI - DNS/뒤 어쩌고 저쩌고 붙는것

 

인그레스 서비스(L7 스위치)가 필요한 이유 

url이 다른 경우도 있고, uri가 다를수 있다

 

url에 따른 서버 접속은 dns 등록(Router53)으로 서비스 단(L4-LB)에서 처리가 가능하다 

uri에 따른 서버 접속은 ALB로 가능 함!(Http를 구분하기 때문에)

 

데이터 패킷이 있을때

L4 스위치인 LB는 도메인 이름까지 보고 서비스를 찾아가고 , L7 스위치는 URI까지 확인하여 서비스를 찾아갈 수 있다

	k8s	Cloud	On-prem
7 layer	Ingress	ALB, Http(s)LB	L7 컨텐츠 스위치
4 layer	Service	NLB	L4 스위치

ALB, NLB 차이점 보기 (접근글 클릭)

https://no-easy-dev.tistory.com/entry/AWS-ALB%EC%99%80-NLB-%EC%B0%A8%EC%9D%B4%EC%A0%90

AWS | ALB와 NLB 차이점

https://potato-yong.tistory.com/131

[ELB] ALB / NLB / CLB / GWLB

 

둘중 어느것을 사용해야 할까?

L4 기능만 필요하다면 굳이 ALB를 사용할 이유는 없다 

nlb, alb를 나눠 사용하는것이 실무에서도 있는 일이다!

 

Service는 OSI 7 layer 중에 transport layer에 속한다 = L4 level

ingress는 url mapping을 한다 = 7 level에 속함

 

+ 현업에서는 uri에 따른 서버 접속에 alb말고 LB(4계층)  + nginx로 구현 하기도 한다

nginx - web engine / web proxy / application / was / api / ... 다 됨

k8s에서 이런 역할은 ingress가 한다

 

Ingress

Ingress

ingress - 명세서, 수행을 지시

Ingress controller - 직접 역할을 수행함

ingress controller의 종류

https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/

 

쿠버네티스 환경에서 수작업으로 ingress를 실행하는 경우

ingress controller를 정의하고 ingress를 사용해야 한다

ingress controller를 설치하면 pod형태로 설치가 된다

ingress controller에 접속하기 위해서 ingress pod에 접근하기 위한 svc가 필요하다

client가 svc에 들어가면 ingress controller에 접근하게 되고, ingress controller가 ingress 명세서를 보고 서비스를 나눈다 

 

managed k8s를 사용하는 경우

ingress controller를 정의하지 않아도 ingress yml만 만들으면 알아서 ingress controller를 정의해준다 (누가? - alb가)

 

ingress 만들기

기본 세팅

- nginx_v1, v1, v3 서비스를 만들어 놓는다 (nodeport 타입으로)

3개 서비스에 대한 ingress.yml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myingress
  labels:
    name: myingress
spec:
  rules:
  - host: v1.mymincloud.com
    http:
      paths:
      - pathType: Prefix
        path: "/"
        backend:
          service:
            name: svc1
            port: 
              number: 80
  - host: v2.mymincloud.com
    http:
      paths:
      - pathType: Prefix
        path: "/"
        backend:
          service:
            name: svc2
            port: 
              number: 80
  - host: v3.mymincloud.com
    http:
      paths:
      - pathType: Prefix
        path: "/"
        backend:
          service:
            name: svc3
            port: 
              number: 80

ingress ip로 접속이 가능한가? 안된다 -> 모든 사이트는 url로 접속 되도록 설정되어 있음

aws - route53에서 dns 추가

url로 접속시 잘 됨

 

이때 dns를 등록할때 ingress ip를 받을때까지 기다려야 한다는 문제가 있다

 

static ip 이용하기

일단 생겼던 ingress 를 지우고 gcp 에서 static ip를 만든다

이때 받은 ip는 바뀌지 않는 ip로 router53 dns를 등록해놓는다

이 ip를 ingress.yml에서 annotaion 옵션을 이용해서 추가해놓으면 해당 ip를 사용하게 된다!

https://cloud.google.com/kubernetes-engine/docs/tutorials/http-balancer

인그레스를 사용한 HTTP(S) 부하 분산 설정  |  Kubernetes Engine  |  Google Cloud

 

TLS 통신

ingress 는 https(TLS 통신)를 지원한다

 

암호화 알고리즘에는 두가지가 있다

1. 대칭키 - 복호화 키 전달에서 문제가 생길 수 있음

2. 비대칭키 - 암호화키 =/= 복호화키 , 서버 부하가 생김

 

TLS 통신중 하나는 대칭키를 비대칭키로 포장해서 전달하는 것 

인증서와 인증서 키가 필요하다

인증서 - 신뢰할 수 있는 기관이 줌

 

나머지는,, 내일~

 

오늘의 회고

• 인그레스 부분을 책으로 봤을때도 어려워가지고 걱정을 많이했는데 관리형 k8s를 사용하니까 구현이 아주 쉬웠다
• 아직  ingress부분이 안끝나서 모르겠지만 오늘한것까지는 적당히 잘 ~ 이해했다
• 나중에 프로젝트때는 대체 어떻게 이 개념을 활용해야할지는 아직도 막막하다 ㅜ!