그냥 기억하기 싫어서 기록하는 블로그

Self-hosted action runner란?GitHub Actions는 코드 변경을 자동으로 감지하여 빌드, 테스트, 배포 등의 작업을 수행할 수 있는 강력한 CI/CD 플랫폼입니다. 기본적으로 GitHub에서는 자체적으로 관리되는 호스티드 러너(Hosted Runner)를 제공하며, 사용자는 별도의 설정 없이 워크플로를 실행할 수 있습니다.하지만 때로는 GitHub에서 제공하는 러너로는 한계가 있을 수 있습니다. 이럴 때 사용하는 것이 바로 self-hosted Action Runner입니다. Self-hosted runner는 GitHub Actions 워크플로를 실행할 수 있는 러너를 사용자가 직접 운영하는 방식으로, GitHub에서 제공하는 러너와 동일한 기능을 제공하면서도 다음과 같은 이점..

Self-hosted action runner란?GitHub Actions는 코드 변경을 자동으로 감지하여 빌드, 테스트, 배포 등의 작업을 수행할 수 있는 강력한 CI/CD 플랫폼입니다. 기본적으로 GitHub에서는 자체적으로 관리되는 호스티드 러너(Hosted Runner)를 제공하며, 사용자는 별도의 설정 없이 워크플로를 실행할 수 있습니다.하지만 때로는 GitHub에서 제공하는 러너로는 한계가 있을 수 있습니다. 이럴 때 사용하는 것이 바로 self-hosted Action Runner입니다. Self-hosted runner는 GitHub Actions 워크플로를 실행할 수 있는 러너를 사용자가 직접 운영하는 방식으로, GitHub에서 제공하는 러너와 동일한 기능을 제공하면서도 다음과 같은 이점..

Kubernetes Pod Resource CPU 설정우리는 Kubernetes에서 Pod를 배포할 때 Node의 리소스 관리를 위하여 Resources에 CPU와 Memory의 사용량을 정의할 수 있습니다. 이때 Memory에 대한 설정은 명확하여 사용자가 알기 쉽지만 CPU에서는 "0.5"와 같은 설정이 가능하여 많은 사람들이 단순하게 "0.5"를 1/2 Core로 이해합니다. 하지만 Kubernetes에서 CPU는 Core가 아닌 CPU Share로 관리되며 CFS(Completely Fair Scheduler)와 밀접한 관계가 있습니다.이번 문서에서는 Kubernetes Pod Resource CPU 설정과 CFS의 관계에 대해 알아보겠습니다.resources: requests: cpu: ..

Helm Hook이란Helm Hook은 Kubernetes에서 Helm을 이용해 리소스를 배포하거나 삭제하는 과정 중에 특정 타이밍에 맞추어 추가 작업을 자동으로 실행할 수 있는 기능입니다. 즉, 단순히 애플리케이션만 배포하는 것이 아닌 설치 전/후, 업그레이드 전/후, 삭제 전/후 등 필요한 다양한 작업을 미리 정의해 놓을 수 있습니다. Helm Hook을 이용하면 복잡한 배포 시나리오를 쉽게 관리할 수 있고 특히 데이터베이스 초기화, 마이그레이션, 시스템 점검, 백업 그리고 CI/CD파이프라인이나 대규모 운영환경에 적용하여 다양한 자동화 작업에 활용할 수 있습니다.이번 문서에서는 Helm Hook의 개념과 사용법에 대해 알아보겠습니다. Helm Hook 작성법Helm Hook은 Helm 차트의 메타데..

Terraform이란?Terraform은 HashiCorp에서 개발한 오픈소스 인프라스트럭처 자동화 도구로, 사용자가 작성한 코드를 이용하여 인프라를 정의하고 관리하는 도구입니다. Terraform을 이용하면 서버, 네트워크, 데이터베이스, 로드 밸런서 등 다양한 인프라 자원을 선언적인 설정 파일(HCL, HashiCorp Configuration Language) 형태로 작성할 수 있으며 이 파일을 기반으로 원하는 클라우드 환경이나 온프레미스 환경에 인프라를 일관되게 구축, 변경, 버전 관리할 수 있습니다.기존에는 인프라 구축을 위해 수동으로 수십 번의 클릭과 설정이 필요했지만 Terraform을 사용하면 한 번의 명령어 실행으로 필요한 모든 인프라를 자동으로 프로비저닝 할 수 있으며, 인프라 변경사항..

GitHub Action이란?GitHub 저장소(repository) 안에서 코드 변경(push, pull request 등)이나 수동 실행(workflow_dispatch), 예약 실행(schedule) 같은 다양한 이벤트를 트리거로 하여 정해진 작업(workflow)을 자동으로 수행할 수 있도록 지원하는 GitHub 내장형 자동화 기능입니다. 사용자는 YAML 파일을 이용해 빌드, 테스트, 배포, 린트 검사, 문서 생성 등 필요한 작업을 정의할 수 있으며, 이러한 작업들은 하나 이상의 Job으로 구성되고, 각 Job은 여러 Step(명령 실행 또는 외부 Action 호출)으로 이루어져 독립적으로 혹은 서로 의존 관계를 갖고 실행될 수 있습니다. GitHub Actions는 GitHub와 완벽하게 통합..

ArgoCD란ArgoCD는 쿠버네티스(Kubernetes) 환경에서 애플리케이션을 안전하고 일관성 있게 배포하고 관리할 수 있도록 도와주는 오픈소스 GitOps 도구입니다. 사용자는 애플리케이션의 설정 파일이나 배포 정보를 Git 저장소에 미리 정의해 두고, ArgoCD는 해당 Git 저장소를 지속적으로 모니터링하여 쿠버네티스 클러스터 내 실제 상태와 비교합니다.만약 Git에 정의된 원하는 상태와 클러스터 내 실제 상태가 다를 경우, ArgoCD는 자동으로 이를 동기화하거나 사용자의 승인 후 동기화를 수행해, 클러스터 상태가 항상 Git 저장소에 정의된 상태와 동일하게 유지되도록 관리합니다.이를 통해 기존처럼 수동으로 애플리케이션을 배포하거나 kubectl 명령어로 직접 리소스를 생성,수정,삭제하는 방식..

Argo Rollouts란?Argo Rollouts는 Kubernetes에서 고급 배포 전략(Canary, Blue-Green 등)을 구현할 수 있도록 도와주는 배포 관리 컨트롤러입니다. 기본 Kubernetes의 Deployment는 새로운 버전이 배포될 때 기존 파드를 점진적으로 교체하는 Rolling Update 방식만 제공하는 반면, Argo Rollouts는 Canary, Blue-Green, Recreate 등 다양한 배포 전략을 지원합니다. 이를 통해 애플리케이션의 안정성을 높이고, 배포 과정에서 발생할 수 있는 문제를 최소화할 수 있습니다.Argo Rollouts는 Argo CD와 함께 사용하여 GitOps 방식으로 배포를 관리할 수 있으며, Argo Workflows와 통합하여 CI/CD..

kubernetes max podsKubernetes 공식 문서에 따르면 기본 설정으로 노드 당 최대 110개의 파드를 생성할 수 있습니다. 이는 노드에서 파드의 IP를 할당하기 위해서입니다. IP 주소 자원은 한정되어 있기 때문에, 노드당 생성할 수 있는 파드 수를 제한하여 네트워크 충돌을 방지하고 안정적인 운영을 보장하고 있습니다. 아래 이미지는 Kubernetes 공식 문서에서 제시하는 기본값입니다.노드는 최대 110개의 파드클러스터는 최대 5000개의 노드클러스터는 최대 150000개의 파드클러스터는 최대 300000개의 컨테이너 kubernetes max pods 개수 수정kubernetes 공식 문서에서 제공하는 기본 값을 사용하는 것을 권장하지만 그래도 상황에 따라 노드의 개수는 늘리지 못하..

컨테이너를 실행할 때, 여러 옵션을 사용하여 실행 중인 컨테이너에 리소스 제한을 설정할 수 있습니다. 이를 통해 컨테이너가 사용할 수 있는 CPU, 메모리, 디스크 공간 등과 같은 리소스 사용을 세밀하게 제어할 수 있습니다. Docker는 일반적으로 리소스를 자동으로 관리하지만, 경우에 따라 직접 리소스 제한을 설정하는 것이 필요할 수 있습니다. 이를 통해 컨테이너의 성능을 최적화하고, 다른 컨테이너나 호스트 시스템과의 리소스 경쟁을 관리할 수 있습니다. 예를 들어, CPU 제한을 설정하여 컨테이너가 특정 CPU 점유율을 초과하지 못하도록 할 수 있고, 메모리 제한을 설정하여 컨테이너가 지정된 메모리 양을 초과하지 않도록 할 수 있습니다. 이러한 리소스 제한 옵션을 사용하면 컨테이너의 안정성과 성능을 개..