클라우드 개발자 앙몬드

EC2를 쓰다보면 장비랑 하드웨어에 이상이 생겨서, 내 버츄얼 호스트 세입자를 내쫓아내야하는 케이스가 생긴댜

사이클은 예측하기 어렵지만 지금까지 경험상 대략 반년에 한번 정도는 생겼던 것 같댜

뭐 잡론은 접고 바로 스텝부터 밟아보쟈

1. 대상 노드 조회

- kubectl get node -l ~~~ -L | grep ~~~

- aws 측에서 node retire 공지가 올 때, 인스턴스 id (i-*) 형태로 온다.

- 이거로 어떤 워커노드에 문제가  생겼는지 조회해서 찾는다.

2. 워커노드 오토스케일링 그룹을 +1

- 지금부터 할 작업은 워커노드 1대를 축출하는 작업이다.

- 안에 기동되어 있던 파드는 즉각적으로 다른 노드로 이사가서 기동되고 서비스를 수행해야 한다

- 원래 이 부분은 옵션인 단계이다. 어차피 노드 컨트롤러가 알아서 1대 다시 기동할텐데, 나는 그 시간까지 기다리기 싫으니 미리 돗자리 펴는 것 ㅇㅇ

- 이 부분은 콘솔로 해도 되고, 테라폼으로 해도 되고, 각자 원하는 방법으로 한다. 

3. 워커노드 drain 

- 워커노드를 방출하는 단계이다

- kubectl drain 문제되는_노드명 --ignore-daemonsets --force --delete-local-data

- drain 노드를 하게 되면, 해당 노드가 스케줄링 불가 상태로 빠지면서 안에 파드가 모두 축출되기 시작한다.

- drain에는 kubectl cordon 과정도 포함되어 있으니, 굳이 drain에 앞서 cordon을 먼저 할 필요까진 없다.

- ignore daemonsets은 kube system critical 레벨로 기동되는 쿠버프록시나 코어dns, CNI 파드들의 필수 생존 여부를 무시하는 옵션이다. 이 옵션없이 drain하는데 에러가 뜨면 데몬셋 무시로 진행해보도록 하자.

- force는 강제이고, delete local data는 의미에서 뭔지 알 수 있다.

4. 노드 삭제

- kubectl delete node 이상한노드명

- 워커노드를 ETCD에서 삭제한다.

- 나머지는 다시 개수를 맞추려고, 1번에서 늘렸던 1개 혹은 2개가 추가로 늘어난 뒤, 스케일링을 줄이면 원래 개수로 맞춰지고 원복할 수 있다 ㅇㅇ

생각보다 좀 복잡하다

RBAC랑 CM까지 따로 건드려야함 ㅇㅇ 

https://medium.com/geekculture/create-a-new-user-in-argocd-using-the-cli-and-configmap-8cbb27cf5904

우선 이 분꺼로 간단하게 될거임

이후 AD연동까지 추가로 가능한 방법이 공홈에 있는데, 그 부분은 나중에 살펴보겠음 ㅇㅇ 

아르고 설치하고 돌리면 뭐 여러개가 뜬다.

레디스에 뭐에 앱 컨트롤러. 아르고 서버 등등등.

근데 사실 중요한건 auto sync. 오토싱크이다.

자동으로 깃에 올라온걸 동기화해서 지금 vs 현재깃 상태를 비교해, 즉각 반영해줘야 함 ㅇㅇ.

AWS 코드 파이프라인 써본 사람은 알거임.

사실 나는 깃 자동 푸시 해놓자마자 지가 알아서 막 바바바박 배포하는거보고 우왕 했었는데.

얘는 이 오토싱크 인터벌. 간격이 3분단위로 흘러감.

담당하는 앱은 어플리케이션 컨트롤러라는 놈이 담당한다.

얘의 앱 로그를 보면 3분마다 로그가 찍히는데, 내가 오토싱크를 켰음에도 불구하고 애가 바로 깃 변경된 사항을 인지하지 못하고, 이것도 3분마다 진행을 한다.

이 인터벌을 줄여야하는데, 헬름차트건 뭐 yaml 템플릿 직접이건 변경할 것은 비슷할것 같다.

STS의 커맨드 중 app resync가 바로 interval을 담당함.

헬름이랑 direct yaml 각각 입맛에 맞게끔 변환해서 쓰자

아르고CD에 함정이 있댜

LB에서 뒤로 보낼 때 꼭 프로토콜 HTTPS로 해서 보내셈

안그러면 443 리디렉션 무한루프 타는 버그가 있음 ㅇㅇㅇ 

kind: Ingress
apiVersion: networking.k8s.io/v1
metadata:
  annotations:
    kubernetes.io/ingress.class: alb #ALB 인그레스 컨트롤러 설치했다면 아마 디폴트로 이 이름일것임
    alb.ingress.kubernetes.io/subnets: 서브넷id-a, b, c
    alb.ingress.kubernetes.io/scheme: internet-facing #퍼블릭
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/backend-protocol: HTTPS #이거 주의하셈. HTTP가 아니라 https로 박으셈. 내가 보기에 무한루프 리디렉션 버그로 보임
    alb.ingress.kubernetes.io/actions.response-404: '{"Type": "fixed-response", "FixedResponseConfig": {"ContentType":"text/plain", "StatusCode":"404", "MessageBody":"404 page not found"}}'
    alb.ingress.kubernetes.io/inbound-cidrs:  "1.2.3.4/32" #대충 인바운드 SG
    alb.ingress.kubernetes.io/certificate-arn: ACM인증서 arn임
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}, {"HTTP":80}]'
    alb.ingress.kubernetes.io/healthcheck-path: /
  name: argocd-ingress 
  namespace: argocd    
spec:
  rules:
  - http:
      paths:
      - backend:
          service:
            name: argo-cd-argocd-server # SVC명인데, 이거 argocd 헬름차트로 설치하면 {릴리즈명}-argocd-server로 되니까 참고하셈
            port:
              number: 80 # 443으로는 안보내봤음. 기타 사람들 확인바람
        path: /*
        pathType: Prefix

대충 내 환경에서 정상 동작한 인그레스 yaml.임

pathType은 공홈 참조 고고. 아마 아르고 공홈에선 Imple을 디폴트로 박았을것임.

아 그리고 내가 헬름차트로 설치한 argo는 다음과 같음.

value 파일에는 HA구성대신 전부 싱글로 설치되는 옵션임.

상세 옵션값은 아티팩트허브 들어가보길 권장함 ㅇㅇ. 헬름 레파랑 뭐 등등 설치하는것 가이드 간단하게 나와있음.

https://artifacthub.io/packages/helm/argo/argo-cd

아 헬름 value 자체에 인그레스 설정값 박을 수 있는데, 레퍼런스가 없어서 그냥 쿠버 독립 인그레스 템플릿으로 배포해도 됨. (위에 내가 한 방식 ㅇㅇ)

아르고 서버 헬름 값의 인그레스 value임. 궁금한 점 있으면 레퍼런스 많이 나올거같음 ㅇㅇ;

무튼 argo CD 인그레스를 ALB로 설치한다면 조심하셈들

https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-cli-install-linux-alt.html

이스티오와 대표 차이점으로, 

링커d는 게이트웨이 따로 필요 없음

이스티오는 별도 LB와 게이트구간이 존재.

뭣보다 링커d가 좀 더 쉽게 접근이 가능하다는건 개인 기분일수도 있음 ㅇㅇ