roki_1213

EKS 1.29 -> 1.30으로 올리는 작업 중 aws-ebs-csi-driver 도 업데이트를 진행하였습니다.

작업 전 기존 aws-ebs-csi-driver  values를 확인하는 작업을 진행하였습니다.

위에 정보를 확인 후 업그레이드를 진행

에러 발생 (??????)

사실 25년 2월 10일에 테스트 환경은 정상 업데이트 했습니다. (aws-ebs-csi-driver  1.39)

원인: 

   helm repo update 진행하면서 1.40 으로 자동 지정 되었고, 1.40브랜치에는 values.schema.json 라는 파일이 생성되었습니다.      (Helm 유효성 검증을 진행하는 파일)

    값(values) (enableVolumeScheduling,enableVolumeResizing 등등) 이미 과거에 제거된 값 이였습니다.

1.39 브랜치 : https://github.com/kubernetes-sigs/aws-ebs-csi-driver/tree/release-1.39/charts/aws-ebs-csi-driver

1.40 브랜치 : https://github.com/kubernetes-sigs/aws-ebs-csi-driver/tree/release-1.40/charts/aws-ebs-csi-driver

해결 : (기존 values 값을 제거)

2번째 이슈 (궁금)

해결 후

helm get values aws-ebs-csi-driver -n kube-system --all -oyaml 에서 enableVolumeResizing 값이 확인이 되고 있습니다...

안녕하세요!

특정 서비스에서 NLB + ALB를 사용하여 고정 IP 및 타켓 라우팅 규칙을 사용하는 예시를 공유 드립니다. 

(구조에 리스닝, 타켓을 개념을 잘 분리해서 작업하면됩니다)

저는 처음에 아래 구조를 보면서 고정IP는 사용이 가능하지만 라우팅 규칙을 사용이 불가능 할 것이라고 생각했습니다..

이유는 NLB L4 에서는 도메인 호스트 (test80.test.com, test81.test.com)을 인식할 수 없다고 생각하여 루프가 발생하는게 아닌가 했습니다.....

하지만 공식 문서에서 지원을 하다고 되어 있습니다! (추정하는것 보다는 테스트 정답 같습니다 ㅠㅠ)

구조

  Router 53 대상(NLB)→ NLB → ALB → 서버 (Nginx 2개 81, 80)

NLB 구조

   리스닝 : 80, 443

   타켓그룹: ALB 80, 443

ALB 구조

   리스닝 :

      80 규칙:

        모든 요청 https 라우팅

      443 규칙:

        test80.test.com → 서버 80 포트

        test81.test.com → 서버 81 포트

개인적으로 테스트한 내용으로 틀린 정보가 있을 확률이 매우 높습니다. 

운영에 적용 전 따로 테스트가 필요합니다.

배포로인한 서비스 연속성(인바운드 트래픽 유실, 아웃바운드 트래픽 유실, 어플리케이션 안정성)에 이슈가 발생하지 않게 하는 것이 중요합니다.

하기 내용은 AWS 환경에서 동작한다는 기준으로 작성했습니다.

배포 진행 시 이슈 (502, 504 발생)

1. 신규 파드에 느린 어플리케이션 시작 (트래픽을 받을 상태가 아닌 상황)

2. 기존 파드에 종료 ( 타켓그룹에서 계속 트래픽을 전달함, 기존 어플리케이션에 정상적인 종료가 안된 상태)

위에 이슈를 조치하기위해 ReadinessGates 를 사용해야됩니다. (aws alb controller사용한다는 기준)

자세한 가이드 (https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.8/deploy/pod_readiness_gate/)
 

ReadinessGates를 사용할 경우 (트래픽을 받을 상태가 아닌 상황, 타켓그룹에서 계속 트래픽을 전달함)을 조치할 수 있습니다. 

하지만 "기존 어플리케이션에 정상적인 종료가 안된 상태"는 조치가 되지 않습니다.

위에 이슈를 조치하는 방법은 preStop, terminationGracePeriodSeconds, alb.ingress.kubernetes.io/target-group-attributes: deregistration_delay.timeout_seconds= 30 예시

참고 블로그 

https://waspro.tistory.com/682

https://pmh.codes/kube/