기록들 https://github.com/ndgndg91

Spring Boot 를 사용하여 서버 어플리케이션을 개발하고 Kubernetes 상에서 운영할 때 Container 의 상태를 확인하고 복구가 불가능한 경우 재시작 시켜야 되는지 알 필요가 있다. 또한 Container 가 트래픽을 받아들일 준비가 되었는지 상태를 알아야한다. 이때 각각 liveness, readiness probes 를 사용한다. 아래와 같이 Kubernetes deployment 에 liveness 와 readiness probes 를 설정한다. initialDelaySeconds 는 Container 가 실행되고 90초 이후에 설정된 path 에 Get 요청을 통해서 정상상태를 확인한다. 200 ~ 399 status code 를 5초이내에 응답 받으면 성공으로 확인한다. periodSeconds 는 10초 주기로 확인한다. 연속해서 3번 비정상 응답을 받을 경우 liveness 는 실패로 돌아가고 Kubelet 은 Container 를 재시작시킨다. 이번엔 Spring Boot 어플리케이션을 보자. gradle 을 사용할 때 아래와 같이 의존성을 추가한다. 그리고 application.yaml 에 아래와 같이 설정한다. 유의해야할 점은 exposure.include 에 * 를 쓰게되면 불필요한 정보가 모두 노출되어 보안에 취약해진다. 예를 들어, heapdump 또는 shutdown 같은 기능을 노출하게 되면 외부에서 공격점이 될 수 있다. /actuator path 요청시 아래와 같이 응답을 받는다.  exposure 에 health, info 만 설정해서 두가지만 확인할 수 있다. /actuator/health 를 확인해보자. endponint.health.probes.enabled=true 로 설정해서 liveness, readiness 를 지원한다. /actuator/health/liveness 와 /actuator/health/readiness 를 확인해보자.  spring boot application 에...

 GitOps 를 구현하는 과정에서 고민했었던 부분 그리고 해결한 방법을 정리하려고 한다. GitOps 에서 크게 Application Repository ( Code Repository ) 와 Environment Repository ( State Repository ) 두 가지의 Repository 로 정의가 된다. 조직의 프로세스나 크기, 형태, 철학마다 다르겠지만, 일반적인 회사에서나 어떤 프로젝트에서 협업을 할 때 보통 개발팀과 운영팀이라는 개념으로 나뉠 수 있을 것이다. 이 때 보통 Application Repository 는 개발팀이 Environment Repository 는 운영팀이 관리할 것이다. 개발팀에서 지속적으로 새로운 기능 및 유지 보수를 진행함에 따라서 소프트웨어의 변경이 일어난다. 해당 변경은 CI 를 통해서 새로운 Container Image 를 생산할 것이다. 이 때 운영팀은 Image 들의 버전을 Environment Repository 에 반영해야 한다.  이 과정에서 여러가지 의문점이 들었다. 운영팀은 Environment Repository 의 Application 들의 버전 변경을 수동으로 반영할까 자동으로 반영할까? 수동으로 반영하는 프로세스라면 휴먼에러가 발생하지 않을까? 발생한다면 어떻게 대처할까? 자동으로 반영한다면 그것또한 무결함을 보장할 수 있을까? 이러한 의문점들은 귀결은 "Environment Repository 를 어떻게 관리하는게 좋을까?" 이다. 조금만 생각해보면 해당 질문에 정답이 있는것은 아니라는 결론이다. 모든것은 현재 해당 프로젝트 해당 조직이 처한 context 에 따라 다를것이다. 규모가 큰 조직일수록 관리해야할 application 이 많아서 수동으로 관리하는 것에 한계를 느낄 것이고, 반대로 규모가 작은 조직일수록 수가 적은 application 들을 관리하기 위해서 자동화를 하는 것에 더 비용을 크게 느낄수 도 있을 것이다.  개인적으로 자동화는 단기적인 관점...

 GitOps 란 무엇인가? cloud native application 의 CD(Continuous Deployment) 의 구현 방법이다. infrastructure 을 운영할 때 Git 을 포함한 CD tools 을 포함하여 이미 개발자들에게 친숙한 tools 을 사용하는 방법을 통해서 개발자 중심적인 경험에 초점을 두고 만들어졌다.  GitOps 의 가장 중심적인 개념은 아래의 3가지이다. 1. automated process (자동화된 프로세스) 2. 현재 infrastructure 상태의 declarative descriptions (선언적인 상세) 3. Git repository  Git repository 는 production 환경에서 현재 infrastructure 의 상태를 기술하는 declarative description 가지며 자동화된 프로세스를 통해서 실제 infrastructure 가 관리된다. 새로운 application 또는 기존의 application 을 update 할 경우, Git repository 을 update 함으로써 infrastructure 를 변경한다. 또한 이는 자동화된 프로세스로 모든것이 이루어진다. 그렇다면 왜 GitOps 를 사용해야 하는가? 더 빠른 그리고 더 자주 배포할 수 있다. 모든 CD technology 는 배포성에 대해서 장점으로 말한다. 하지만 GitOps 가 특별한 점은 배포를 위해서 CD tools 변경이 필요없다는 점이다. 모든것이 VCS (version control system) 을 통해서 이루어진다. 쉽고 빠른 Error Recovery GitOps 는 모든 infrastructure 의 변경 내역이 Git repository 에 관리된다. 또한 error recovery 를 위해서 git revert 를 진행하고 복구되는 것을 지켜보기만 하면 된다. 쉬운 Credential 관리 오직 Git repository 와 image registry 만 필요하다...

 https://github.com/awslabs/amazon-eks-ami/blob/master/files/eni-max-pods.txt 이번에는 eks cluster 의 worker node 를 fargate 대신, managed 혹은 un-managed node group 으로 관리할 때 생길 수 있는 이슈인 Pod Limit 에 대해 정리해보겠다. 제일 먼저 올린 링크에서 확인할 수 있듯이, ec2 type 에 따라 pod 를 deploy 할 수 있는 제한이 있다. t3.micro 의 경우 pod 제한이 4개, t3.nano 도 pod 제한이 4개 이다. Pod Limit 이 어떤 상황을 야기시킬 수 있을지 테스트해보자. 먼저, cluster 를 만든다. eksctl create cluster --version 1.17 --name pod-test --node-type t3.micro --nodes 2 kubectl get ns 명령어로 namespace 를 확인한다. kube-system namespace 의 pods 들을 확인할 수 있다.  해당 pod 들은 k8s 시스템에서 생성한 오브젝트들로, k8s cluster 구성에 필수적인 컴포넌트들과 설정값 들이다. 이미 위에서 t3.micro type 으로 node 를 생성했고, t3.micro 의 pod limit 은 4 이다. 이미, kube-system 네임스페이스에 6개의 pod 가 running 하고 있다.  2 node (t3.micro)  * 4 (pod limit per t3.micro) = 8 (pod limit) 이며, 즉 추가적으로 running 가능한 pod 의 수는 2개가 된다.  그렇다면 이제 2개 이상의 pod 를 deploy 해보자. 해당 yaml 파일을 통해서 replicas 3 을 통해 desired pod 수는 3이다. 하지만, 결과는 1개의 pod 는 pending status 라는 것을 확인할 수 있다? 원인은 바로 0/2...

https://github.com/ndgndg91/eks-practice eksctl 을 사용하기 위해서 필요한 것은 4가지이다. https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/getting-started-eksctl.html 1. aws cli 설치 - aws cli 기존에 설치되어 있어도 반드시 버전을 확인해야 한다. eksctl 을 사용하기 위해서는 aws cli 1 버전을 사용하는 경우 1.18.149 이상이여야 하며, aws cli 2 버전의 경우 2.0.52 이상이여야 한다. 기존에 https://docs.aws.amazon.com/ko_kr/cli/latest/userguide/install-cliv2-mac.html#cliv2-mac-install-gui 2. aws cli 를 버전에 맞게 설치했다면, aws configure 를 통해서 올바른 role 을 가진 IAM user 의 access_key, secret_access_key 를 등록해주자. 3. 다음으로 중요한 k8s 클러스터를 제어하기 위한 kubectl 을 설치하자. homebrew 패키지 매니저를 이용하면 간단하게 설치가 가능하다. https://kubernetes.io/ko/docs/tasks/tools/install-kubectl/ https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/install-kubectl.html 4. 마지막으로 eksctl  https://github.com/weaveworks/eksctl - aws cli version - aws cli configure 확인 - kubectl version 확인 - eksctl version 확인 eksctl 명령어로 cluster 만들기 eksctl create cluster --name eksctl-test --nodegroup-name ng-default --node-type t3.micro --nodes ...