클라우드 개발자 앙몬드

설치 이렇게 하시고 

https://www.opsmx.com/blog/how-to-setup-ldap-and-openldap-for-argocd/

LDAP 연동을 위한 아르고 헬름 덱스서버 설정은 이거 보셈.

위에꺼 중 중간 과정에 LDAP config 관련 절차 나옴 ㅇㅇ 

그떄 이거로 들어가서 보시면 됨 

https://medium.com/yapi-kredi-teknoloji/argo-cd-ldap-authentication-and-rbac-configuration-7c1b7b0cb7a1#:~:text=LDAP%20Configuration,drive%20authentication%20for%20other%20apps

생각해보면, 도커 빌드에 파드 생성, SVC연결, 인그레스 연결, 기타 쿠버충들의 생태계까지 구축하고 버전업을 인플레이스까지 해보았다.

근데 로그쪽은 항상 중요하게 생각하면서도 내가 처음부터 구축해본 적이 없었다는 것을 최근 깨달았댜 ㅇㅇ..

요즘 로그 첫 구축 시도해보려고 하는데, 신기한게 있어서 우선 여따 적어놓는다

로그의 트러블슈팅이자 스트리밍 구간은 크게 2개이다.

1. 로그가 호스트에 떨어지는가.

2. 로그를 정제해서 스토리지로 전달했는가.

이 중 1번이 관건. 

파드 표준 출력 로그가 /var/log/containers (아눅스2 EKS 최적화 이미지 기준) 에 떨궈지는데, 이게 항상 json 포맷으로 떨어지더라 ㅇㅇ 

대충 형태가

{"log" : "표준출력 로그임 ㅇㅇ"}

이렇게 떨어짐.

나는 저 log라는 json키를 붙인 적이 없는데, 저걸 붙이는 범인은 누구였을까.

처음에는 쿠버가 붙이는줄 알고 별 짓거리를 다했는데, 알고보니 그냥 도커의 디폴트 로그 드라이버가 json으로 떨어짐 ㅇㅇ 참고하셈

https://docs.docker.com/config/containers/logging/json-file/ 

도커로 진짜 날로 배우고 왔었는데 하.. 컨테이너d 가도 이런 기본적인 포맷들이나 특성들은 유지가 되겠지? 흠 

람다를 4년가까이 썼는데, 모르는게 아직도 많은 것 같다

글로벌 선언 시 최초 콜드스타트 시점에 일반 오브젝트들만 유지하는게 아니라 커넥션도 유지하는거였다는 사실을 왜 이제 알았을까

람다의 라이프사이클 얘기가 나오는데, 최초 초기화 때 커넥션 재사용하는 부분이 나와있다.

하나 또 잘 배웠다 굳

https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtime-environment.html#runtimes-lifecycle-ib

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 각각 입맛에 맞게끔 변환해서 쓰자