roki_1213

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

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

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

하기 내용은 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/

EKS 안에 프로메테우스, 그라파나를 구성하여 사용하고 있습니다. 

기본적으로 pod의 메트릭은 수집되고 있지만 그 외 EC2의 메트릭은 수집되고 있지 않았습니다.

Node exporter 를 EC2에 구성 후 프로메테우스 설정 (job)에 등록하여 배포 (수동)으로 진행 중 

ec2_sd_configs 라는 것을 알게되어 구성해보았습니다. 

1. 프로메테우스 pod 에 AmazonEC2ReadOnlyAccess 권한을 부여하였습니다.

https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/associate-service-account-role.html

2. 프로메테우스 헬름 설정 추가

설정을 설명하면

prometheus-ec2-role 는 위에 1번에서 생성한 SA를 입력해주면 됩니다. ( ec2 tag 확인 및 메타데이터 확인 용도)

ec2_exporter 는 메트릭 수집 대상을 인식하기 위한 설정 및 라벨 수정에 사용됩니다.

serviceAccounts:
  server:
    create: false
    name: "prometheus-ec2-role"
    
    
 - job_name: ec2_exporter
    relabel_configs:
      - source_labels: [__meta_ec2_tag_Name]
        target_label: instance
      - source_labels: [__meta_ec2_private_ip]
        target_label: ip
    ec2_sd_configs:
      - region: ap-northeast-2
        port: 9100
        filters: 
          - name: tag:prometheus
            values: 
              - prometheus

기존 프로세스 

- ec2 node expoter 설치 -> 프로메테우스 설정 수정 -> 배포 -> 그라파나 확인 

변경 프로세스

- ec2 node expoter 설치 -> ec2 Tag 설정 -> 그라파나 확인

주의사항: 

- 프로메테우스에서 바로 ec2를 인식하지 않습니다.  (대충 5분에 한번?)

- 잠시 생성되고 삭제되는 서비스가 있으면 eks crontjob를 검토 필요 (사실 잘모르겠습니다 ㅠㅠ)

참고 블로그

https://koudingspawn.de/prometheus-aws-discovery/

https://prometheus.io/docs/prometheus/2.41/configuration/configuration/

https://blog.bespinglobal.com/post/prometheus-설정-가이드/

개인 AWS 에서 EKS 테스트를 자주 진행하고 있었습니다. 

EKS 생성은 하기 링크를 사용했습니다. 

https://gasidaseo.notion.site/Amazon-EKS-23-6-6-16ed4098c3314802a1e4dbf12a9d1da8

alb 생성은 공식 문서를 보고 진행했고 계속 실패를 했습니다 

에러 예시

1 existing iamserviceaccount(s) (kube-system/aws-load-balancer-controller) will be excluded
1 iamserviceaccount (kube-system/aws-node) was included (based on the include/exclude rules)
1 iamserviceaccount (kube-system/aws-load-balancer-controller) was excluded (based on the include/exclude rules)
metadata of serviceaccounts that exist in Kubernetes will be updated, as --override-existing-serviceaccounts was set

원인은 제가 동일한 이름에 정책, 롤 (lb 컨트롤러)를 생성한것이 문제였습니다.

(기타 문제 : 과거 테스트에서 생성한 oidc가 등록되어 있음... )

조치 :

Clodformation 에서 컨트롤러 생성 스택 제거 

1.kubepug

https://kubepug.xyz/usage/

https://boostbrothers.github.io/2023-07-16-infra-eks-update/

참고 문서

2. kubent

https://github.com/doitintl/kube-no-trouble

참고 :

https://jenakim47.tistory.com/97

https://www.jacobbaek.com/1506

최근 eks 클러스터를 구성하면서 node group 서브넷을 지정하지 않고 생성하여 프라이빗, 퍼블릿이 설정되었습니다.

eks 노드그룹에서 퍼블릭 서브넷을 사용하는 경우 퍼블릿 ipr가 자동으로 할당되고  2024년 2월 1일 부터 퍼블릭 ip 비용 정책이 변경되어

불 필요 비용이 발생할 것으로 생각 후 eks worknode 서브넷 그룹 변경하고 합니다!

처음에는 node그룹과 연결된 ASG 에서 서브넷을 수정 후 잘 처리가 됐다고 생각했지만, 추후 문제가 발생했습니다.

eks 버전 업데이트 및 최신 패치가 적용된 이미지 업데이트가 실패 했습니다.

이유는 eks 노드 그룹을 지정하고 있는 서브넷과 ASG 서브넷일 달라서 Degraded 상태로 변경되었습니다.

조치 방법은 기존 node를 마이그레이션 하는 방법 밖에 없습니다....

다행이 eksctl 클러스터를 구성해서 편하게 마이그레이션 했습니다.

방법 : https://docs.aws.amazon.com/eks/latest/userguide/migrate-stack.html

저는 node group yaml 작성 후 신규 노드 그룹을 생성 후 기존 node를 제거 했습니다.

현재 운영하는 서비스가 없어서 추가 이슈 사항이 있는지 확인 안해봤습니다. (실제 운영 서비스가 있으면 이슈가 있는지 확인이 필요합니다.)

참고 : 노드 health 방법

eksctl utils nodegroup-health --name=test-node  --cluster=test-eks

이슈 사항 : pod 내부에서  aws 리소스 (rds.amazon.com)및  외부 서비스 (ex. www.naver.com) timeout 발생

히스토리:

1. 특정 큰 이벤트 중 발생 (많은 세션 발생)

2. 이벤트에 사용하지 않는 pod에서도 이슈 발생

원인 추정:

1번 이벤트 중 외부로 나가는 세션이 nat를 타고 나가고 외부 도메인, 내부 리소스 도메인 쿼리를 많이 보내서 coredns에 부하가 있는 것으로 추정 

2번 nat 리소스 제한이 걸렸다. (X)

조치 : 

1. coredns sale up, out 진행

2. dns configmap  log 설정 (추후 로깅 서비스 추가 필요 elk?)

참고 :

coredns 로그 설정 켜기 (다른 로깅 서비스 연결 필요)

----------------
kind: ConfigMap
apiVersion: v1
data:
  Corefile: |
    .:53 {
        log                  # Enabling CoreDNS Logging
        errors
        health
        ...
----------------

로그 확인 및 저장 (임시 테스트)

kubectl logs --follow -n kube-system --selector 'k8s-app=kube-dns' --timestamps --since-time "$(date -u +'%Y-%m-%dT%H:%M:%S.%N%:z' --date='-1 hour')" >>  ./corednsyyyymmdd.txt  

알 수 없는 정보 :

1. fargate node? pod? 리소스 제한 (네트워크 대역폭, i/o 속도) 해당 정보는 aws 서포트팀에서 오픈을 할 수 없다고 합니다.

2. coredns 모니터링에서는 cpu, 메모리 이슈는 없었습니다. (어디서 부하가 있었는지 확인이 어렵습니다.)

fargate 보다는 worker node 사용이 안정적 일 것 같습니다..

다양한 래퍼런스도 많고......