네트워크 스터디 6주차

 

 

 

<목차>

- 1. ingress 실습환경 구성

- 2. ingress 실습

- 3. ingress 실습 시 반드시 기억해야하는 부분

- 4. gateway api 와 관련해서 출현하게된 배경 조금 더 근본적인 클라우드 네트워킹에 대해 다뤄볼 예정 -> ingress vs gateway api

 

 

4번 부분을 보면서 ->  네트워킹 패러다임이 중앙집중화에서 분산형으로 간다는 것이 이해가 되었고 -> 그렇기 때문에 ingress 의 통합된 기능으로 진행되던 부분이 역할에 따라 기능이 세분화 되어 있는 gateway api 흐름으로 이어진다는 것이 이해가 되었다. 

 

 

 

 

간단한 k3s 구조 설명

k3s server 

 

 

 

프로세스가 하나의 서버에 컴포넌트 조합들로 통합되어 잇음

 

 

 

helm에서 기본적으로 설치할때는 홈디렉토리를 보고 있어서

 

k3s flannel

 

vxlan

 

Nginx Ingress를 사용할 예정

 

 

ingress 발전단계를 이해하고 있어야 함. 지금은 7단계

 

 

ingress 는 책원고 내용을 그대로 실습하고, 이해했습니다.

 

 

 

 

 

AWS NLP, ALP, AWS VPC CNI 환경의 IP 모드에서 동작하기 때문에 내부 파드의 대역대가 동일하다. 

 

 

 

Layer 4 - TCP, UDP, SCTP

Layer 7 - HTTPS

 

 

 

 

 

 

 

• 간편한 테스트롤 위해서 NodePort 타입(externalTrafficPolicy: Local) 설정

 

 

F5 가 kubernetess 쪽에 넘김

https://github.com/kubernetes/ingress-nginx

GitHub - kubernetes/ingress-nginx: Ingress NGINX Controller for Kubernetes

 

 

 

ingress-nginx controller의 동작원리는  nginx.conf를 반영시켜 주는 것이고, reload가 필요할때와 reload를 피해야할 때가 존재함

 

 

 

reload를 해야할 때 reload를 피해야할 때

 

 

helm에서 검색시 주의 kubernetess에서 관리하는 것과 F5가 관리하는것 

 

cf) AWS 관련 ingress 내용

aws 관련 내용 - 디폴트가 인스턴스 모드(nodeport 방식) / IP 모드 (ingress 방식)

 

 

이런 컨셉을 AWS NLB, ALB 의 IP모드로 동작하면 AWS VPC CNI 환경이다 보니, POD대역하고 NLP 내부 대역대가 동일해서 바로 POD로 갈수 있음

 

 

https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.1/guide/service/nlb_ip_mode/

 

https://awskocaptain.gitbook.io/aws-builders-eks/6.-aws-load-balancer-controller

https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.1/guide/service/nlb_ip_mode/

 

 

 

 

 

 

 

 

 

 

Source IP 변경을 변경하지 않기 위해

 

 

 

 

필요한 annotation은 추가하면된다. (allow-snippet-annotations)

 

 

 

 

모든 트래픽이 ingress-nginx-controller 를 거쳐서 간다.

 

 

 

 

 

 

/etc/rancher/k3s/ 

 

각 파드가 제공가능한 CIDR

 

 

 

 

 

 

 

 

===============================================실습환경 구성===============================

 

실습을 통해서 꼭 알아야 둬야 할 것 - X-Forwarded-For 헤더 

맨처음 IP가 client ip

 

cf) https://docs.djangoproject.com/en/4.0/ref/request-response/#methods

Request and response objects | Django documentation

django에도 있음

 

 

접근 해봄

 

 

여기서 가리키는 clinet_address는 ingress-ngin-controller의 IP

 

 

 

 

1. client ip는 ingress-nginx controller가 설치된 pod의 ip를 가리킴

2. ingress-nginx controller 가 service account role을 부여받았기 때문에 api-server를 호출해서 pod ip를 가져올수 있기 때문에 직접 지르는 것이 가능하다. 

 

 

2. nginx 설정 정보를 ingress-nginx controller가 알아서 해준다.

3. 알아서 부하 분산 해주고, routing, host 기반 전달 가능

4. svc 가 cluster ip든 ,nodeport(굳이 열필요가 없다)든 상관 없이 pod의 직접 Ip로 들어간다.

5. aws alb mode defualt instance mode, ip mode

 

 

 

k3s 기본적으로 taint 없어서 taint 생성

 

 

 

 

 

 

ngix.conf 가 자동으로 반영됨

 

L4장비는 4계층 까지만 통제(NLB), ingess

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

https://www.youtube.com/watch?v=0LVI9WOd3qY&t=769s

 

 

 

 

카나리 배포 예시

======================================================================================

# gateway api

 

https://godofcheerup.tistory.com/118

24년 10월 8일 AWS Operation Modernization Day(오프라인) - 역삼 센터필드

 

해당 내용도 참고하면 좋음

 

외워야 하는 내용 

 

0. Role 기반

1. gateway api 가 나오게된 배경 -> 뇌피셜이야기를 해주심

ingress기반에 add on이 각각의 벤더사별로 우후죽순하게 다양해지고, 표준이 없어져서 이러한 기능을 통합할 수 있는 gateway api를 만들었다.

2. 데이터 플레인은 envoy가 핵심  # - 지금 나와있는 모든 gateway 가 데이터 플레인은 envoy를 사용한다.

 

"migrate"라는 단어가 사용된 이유는, 다크 론칭(헤더 기반 라우팅)과 카나리 릴리스(퍼센트 기반 라우팅)와 같은 서비스 배포 기술들을 Gateway API 표준에서 지원하도록 전환하는 과정에 초점을 맞추기 때문입니다. 보통 "migrate"는 하나의 시스템이나 표준에서 다른 것으로 옮겨가는 것을 의미하지만, 이 경우에는 기존의 서비스 라우팅 기법(예: Ingress 또는 다른 메커니즘을 사용해왔던 것)을 Gateway API의 더 발전된 기능으로 적용하는 것을 의미합니다.

 

 

 

Gateway API 를 논하기 전에 

 

애플리케이션 네트워킹에 대해 먼저

 

- 서비스 디스커버리: 서비스 엔드포인트를 찾기위한 작업 -> 서비스 엔드포인트들을 연결하는 작업이 필요

 

내 서비스는 어디에? (서비스 디스커버리)

내 서비스 연결은 어덯게? (서비스 연결)

 

클라이언트 사이드 - 우선 서비스 레지스트리에 엔드포인트를 등록하는 절차가 선행되어야 한다.

 

 

 

 

 

 

 

 

====================

 

 

cf)

 

https://www.youtube.com/watch?v=9FKbQRu6lVs&t=1745s

https://www.youtube.com/watch?v=zJQokt9DP5Y&t=346s