089 089

Telepresence? 로컬 머신에서 Kubernetes 클러스터의 서비스를 개발하고 디버깅할 수 있게 해주는 오픈소스 도구이다. 클러스터 내의 네트워크 환경을 로컬로 연결하여, 개발자가 로컬에서 코드 변경을 하고 결과를 실시간으로 테스트 하면서 클러스터의 다른 서비스와 상호작용할 수 있도록 도와줍니다. 특히 마이크로서비스 기반의 애플리케이션 개발에 유용하며, 로컬에서 클라우드 환경의 리소스를사용할 수 있게 함으로써 개발 사이클을 빠르게 반복할 수 있도록 도와줍니다. Telepresence 이전에 로컬 환경에서 Kubernetes 클러스터의 서비스에 접근하기 위한 방법은? 1. Port Forwarding : 클러스터 내부 서비스의 포트를 로컬 포트에 바인딩하여 접근하는 방법 2. NodePort/L..

도입 이유 쿠버네티스는 시스템을 유지하기 위해 자체적으로 오류를 감지하고 복구하는 메커니즘을 가지고 있습니다. (self-healing기능) 예를 들어 컨테이너가 비정상적으로 종료되거나 반응이 없을 때, 해당 Pod를 자동으로 재시작 합니다. Pod가 재시작되면 해당 Pod가 사용하던 컨테이너 인스턴스는 제거되고, 새로운 컨테이너와 인스턴스가 생성되는 과정에 기존 컨테이너 로컬 저장소에 있던 로그 파일들은 삭제가 됩니다. Pod안에 임시 볼륨이 삭제되고 새로운 파일 시스템이 생성되기 때문입니다. 하지만 운영을 하는 입장에서 왜 Pod가 재시작이 되었는지 알아야 되기 때문에 컨테이너가 살아있을때 외부 로그 저장소에 로그를 수집,저장,분석하여 서비스의 안정성 및 로그 관리를 위해 EFK를 도입 했습니다. 개..

도입이유 프로젝트를 진행하던 중 어떻게 하면 모니터링을 효율적으로 사용할 수 있을까, 대시보드를 세분화 할까 ~~ 근데 Grafana를 하루종일 볼 수 없잖아 등등 커뮤니케이션을 하는 도중 Slack을 이용한 Alertmanager를 도입하기로 결정했습니다. Alertmanager는 Slack을 포함한 다양한 수신자에게 경고를 보낼 수 있는 기능을 제공합니다. Kubernetes 클라우드 환경에서 운영되는 서비스와 애플리케이션의 상태를 Prometheus를 통해 모니터링하고 있는 상황에서 Prometheus가 제공하는 Alertmanager 사용하는것이 맞다고 판단했습니다. 또한, Grafana 대시보드를 지속적으로 모니터링하는 것이 실용적이지 않다고 판단했고 현재 진행하는 프로젝트는 비용적인 제한이 있..

Springboot프로젝트를 이용한 Log 모니터링 helm차트를 이용해 opensearch를 저장소 연결 helm repo add opensearch http://opensearch-project.github.io/helm-charts/ 다음으로 opensearch라는 namespace를 생성 k create namespace opensearch 연결한 helm저장소에 있는 opensearch를 설치 helm -n opensearch install opensearch opensearch/opensearch opensearch는 대시보드를 지원한다. 대시보드도 설치 해주자 helm -n opensearch install dashboard opensearch/opensearch-dashboards 잘 설치..

리소스 할당(Resource Allocation) 을 사용하는 이유 ? 성능 보장 : 각 컨테이너에 적절한 CPU 및 메모리 리소스를 할당하여 안정적인 성능 유지 가능 효율적인 자원 활용 : 리소스 제한을 설정하여 무제한으로 활장하는 것을 방지하고, 효율적으로 자원 활용 가능 주의사항 과도한 리소스 할당 : 너무 큰 리소스를 할당하면 클러스터의 자원이 비효율적으로 사용될 수 있음 너무 작은 리소스 할당 : 너무 작은 리소스를 할당하면 애플리케이션이 예상치 못한 성능 저하를 겪을 수 있음 예시) 잘못된 리소스 할당 문제 : Pod에 대한 메모리 리소스를 지나치게 낮게 설정 결과 : 메모리 부족으로 인한 애플리케이션 성능 저하 컨테이너 리소스 설정 Kubernetes에서는 각 컨테이너에 대한 CPU 및 메모..

Probe? Probe는 컨테이너에서 kubelet에 의해 주기적으로 수행되는 진단이다. Probe를 통해 쿠버네티스는 각 컨테이너의 상태를 주기적으로 체크한 후, 문제가 있는 컨테이너를 자동으로 재시작하거나 또는 문제가 있는 컨테이를 서비스에서 제외할 수 있다. kubelet은 컨테이너의 상태를 진단하기 위해 핸들러를 호출하는데 핸들러는 수행하는 작업의 분류에 따라서 ExecAction, TCPSocketAction, HttpGetAction으로 나뉜다. Handler 컨테이너의 상태를 진단하기 위해 어떻게 진단할 것인지 명시한 것이 Handler이다. ExecAction ExecAction은 컨테이너에서 지정된 명령어를 실행 exit code가 0이면 성공, 이외값은 실패로 분류 exec: comma..

Worker Node 노드는 Pod들을 구동하기 위해 필요한 서비스들을 가지며, 마스터 컴포넌트에 의해 관리된다. 실제 어플리케이션이 실행되는 노드로 Kubelet과 kube-proxy라는 구성요소를 가지고있다. Kubelet Kubelet은 지속적으로 원하는 상태와 관련된 정보, 예를 들면 control plane에서 호출 를 받아와 컨테이너를 실행하고, 해당 상태를 유지합니다. Pod가 스케줄러에 의해 스케줄링되면 API 서버는 kubelet에게 Pod를 생성하라는 요청을 보냅니다. Kubelet은 이 요청을 받아 지정된 컨테이너 런타임과 이미지를 사용해 컨테이너를 생성하고 실행 중인 컨테이너를 모니터링하여 관련된 정보를 API 서버에게 보내게 됩니다. 만약 Liveness Probe가 설정되어 있는..

Kubernetes Architecture 쿠버네티스 아키텍처는 컨테이너화된 워크로드를 안정적이고 적응 가능한 환경을 제공하기 위해, 여러 서버와 클러스터에 분산된 컴포넌트들이 함께 동작하는 집합입니다. 쿠버네티스 클러스터는 컨트롤 플레인 Control plane과 워커 노드 Worker Node로 구성됩니다. 둘 중 컨트롤 플레인에 대해서 알아보겠습니다. 전반적으로 컨트롤 플레인은 전체 클러스터를 관리하고, API를 노출하며, 원하는 구정에 따라 컴퓨팅 노드의 시작 및 종료를 스케줄링 합니다. kubernetes Components kubernetes 아키텍처는 master, worker 모델 구조를 따릅니다. 컨트롤 플레인에 해당하는 master는 워커 노드들을 관리하며, Pod들로 캡슐화된 컨테이너..