카샤의 만개시기

쿠버네티스에서 레이블과 어노테이션은 모두 key-value 형식으로 메타 데이터를 제공한다는데서 동일함을 가집니다. 그렇다면 두 기능의 차이점에 대해 알아보도록 하겠습니다. 레이블 (Label) 가장 큰 차이점은 레이블은 쿠버네티스 리소스를 식별한다는 것입니다. 그로인해 레이블은 서비스 셀렉터와 같이 관련된 리소스 그룹을 지정하는데 사용할수 있습니다. 또한 키와 값의 구조가 제한되어 있기때문에 최적화 된 데이터 구조와 알고리즘을 사용하여 쿼리를 빠르게 평가할 수 있습니다. 레이블의 키와 값 구조에 대한 제한 어노테이션 (Annotation) 어노테이션은 비식별 정보이며 쿠버네티스 내부에서 사용할수 없습니다. 하지만 헬름과 같은 외부 툴이나 라이브러리에서 참조하여 사용할수 있습니다. 어노테이션의 양이 크더..

https://github.com/kubernetes-sigs/descheduler

쿠버네티스에서는 리소스 부족을 처리하기 위하여 쿠버네티스 메트릭(metrics.k8s.io) 외부 정의 메트릭(external.metrics.k8s.io) 사용자 정의 메트릭 (custom.metrics.k8s.io) 위 메트릭 정보를 참고하여 하기 3가지 방식의 오토 스케일러를 사용한다. Horizontal Pod Autoscaler (HPA) 클러스터의 Pod 수를 조정하여 오토스케일하는 방법이다. HPA의 메트릭 허용 오차 값의 default 값은 10%이다. Metrics 값을 지속적으로(default 30sec) 체크한다. 임계치를 넘으면 Pod 수를 늘리기 위한 이벤트가 시작된다. Deployment / Replication Controller에 레플리카 수를 갱신한다. Deployment /..

특정 파드가 너무 많은 리소스를 점유하게 되면 같은 노드에 있는 다른 파드에 영향을 줄 수 있기 때문에 스케줄러는 각 파드가 최대/최소로 사용 가능한 리소스 요구 사항을 파악하고 이에 맞게 효율적으로 스케줄링해야 한다. 리소스 요청 파드를 실행하기 위한 최소 리소스 양을 지정한다. 파드를 실행하기 위한 최소한의 리소스를 가지고 있는 노드가 존재하지 않는다면 여유 용량이 확보될 때까지 대기 상태로 기다린다. 리소스 상한 파드가 사용할 수 있는 최대 리소스 양을 지정한다. 파드가 최대 상한을 초과하려 한다면 해당 파드는 요청이 제한되고 상한을 초과하였을 경우에는 파드가 종료되고 다시 스케줄링되어 동일 노드에서 재시작 된다. spec: containers: - name: cafe image: kakao/caf..

컨테이너된 App은 스턱(Stuck) 상태에 빠지곤 하는데, 이러한 상황을 감지하고 재시작하여 문제를 해결할 수 있어야한다. 활성 프로브 (liveness probe) 컨테이너가 정상적으로 작동하는지 확인하기 위해 헬스 체크를 컨테이너 스펙에 지정할 수 있다. App이 HTTP 응답코드에 2xx나 3xx 상태 코드를 반환할 경우 활성 상태로 판단하고 다른 값으로 응답하거나 응답하지 않으면 컨테이너가 죽은 것으로 판단하고 컨테이너를 재시작한다. livenessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 3 periodSeconds: 3컨테이너가 시작하자 마자 활성 상태를 체크할 경우 어플리케이션은 준비중이기 때문에 응답 코드를 반환하지 못..

헬름은 쿠버네티스 리소스 집합을 나타내는 차트를 관리하기 위한 패키지 매니저이다. 쿠버네티스 서비스를 운영하기 위해서는 Phase(dev,stage,prod 등) 별로 클러스터를 구성하기도 하고 미들웨어를 컨피그맵, 인그레스 등 여러 종류의 리소스를 조합하는 형태로 배포하는데 각 Phase마다 혹은 조합마다 메타 정보들이 많이 달라지게 된다. 그럴때 각 환경마다 매니페스트를 작성하여 관리한다면 관리 포인트가 너무나 많아질 것이기 때문에 배포 환경에 따라 달라지는 설정 값들만 정의하여 배포하는 매커니즘이 헬름이다. Helm 구조 헬름은 클라이언트와 서버(Tiller)로 구성된다. helm client : 사용자를 위한 CLI client tiller : 서버는 클라이언트로부터 전달받은 명령에 따라 클러스터..

컨트롤 플레인 클러스터의 두뇌 역활을 수행하며 컨테이너 스케줄링, 서비스 관리, API 관리 요청 처리 등의 작업을 수행한다. 컨트롤 플레인 컴포넌트는 클러스터 내 마스터 노드에서 실행된다. kube-apiserver 컨트롤 플레인의 프론트엔드 서버로 API 요청을 처리하며 모든 통신은 kube-apiserver가 중심이다. 특히 etcd에는 kube-apiserver만 접근 가능하다. etcd 어떤 노드와 리소스가 존재하는지 저장하는 key-value 데이터베이스. etcd는 서버 하나당 프로세스 1개만 사용할 수 있으므로, 보통 etcd자체를 클러스터링한 후 여러개 마스터 서버에 분산해서 실행해 데이터의 안정성을 보장한다. kube-scheduler 대기열에서 스케줄링되지 않은 파드를 찾아 생성하고 ..

Apache에서 개발한 순수 자바로 개발된 성능 테스팅 도구이다. Web Application을 테스팅하기 위해 디자인 되었지만, 플러그인을 이용하여 다른 기능도 테스트 할수 있도록 확장 할 수 있다. 주요 특징 Jenkins와 연동을 지원한다. Swing 기반의 Component를 지원하기 때문에 GUI가 이쁘지 않다. (중요) 플러그인을 이용하여 테스트 케이스를 XML 형식으로 작성 할 수 있다. Load Test, Distributed Test, Functional Test 등을 지원한다. 동시 스레드를 사용하여 다양한 사용자를 시뮬레이션하고 target에 대한 load를 생성할 수 있다. 웹 응용 프로그램, 데이터베이스, 서버 테스트에서 작동하며 HTTP, JDBC, LDAP, SOAP, JMS ..