본문 바로가기

반응형

K8S

쿠버네티스(Kubernetes) 레플리카셋 (ReplicaSet) ■ 쿠버네티스(Kubernetes) 레플리카셋 (ReplicaSet) 개요레플리카 파드 집합의 실행을 항상 안정적으로 유지하는 것을 목적으로 한다. 즉, 정의된 수량 만큼의 파드를 유지하여 가용성을 모증하는데 사용 된다. 레플리카셋을 단독으로 사용하는 것은 권장하지 않으며, 선언적 업데이트를 수행하는 디플로이먼트라는 상위 개념이 존재 하기 떄문에 레플리카셋을 직접 사용하기 보다 디플로이먼트를 사용하는 것을 권장 한다.사용자는 레플리카셋 오브젝트를 직접 조작할 필요 없이 디플로이먼트를 사용하고 이를 통해서 레플리카셋을 제어하는 방식이 권장 된다. 디플로이먼트에 의해서 생성된 레플리카셋만 제어 가능하고, 사용자에 의해서 생성된 레플리카셋은 제어가 불가능 하다.  ■ 쿠버네티스(Kubernetes) 레플리카셋.. 더보기
쿠버네티스(Kubernetes) 디플로이먼트 (Deployment) 스케일링 ■ 쿠버네티스(Kubernetes) 디플로이먼트 (Deployment) 일반적인 스케일링`kubectl scale deployment/[이름] --replicas=10`디플로이먼트에서 관리하고 있는 파드의 수량을 10개로 증가 시킨다.  별도의 조건이나 상태 확인 없이 증가 시킨다.`kubectl autoscale deployment/[이름] --min=10 --max=15 --cpu-percent=80`평균 CPU 사용량 80% 유지최소 레플리카 수량 10개최대 레플리카 수량 15개정의된 CPU 사용량을 유지하기 위해 레플리카의 수량을 조절하는 방식을 HPA (Horizontal Pod Autoscaler)라고 하며, HPA를 사용한다면 디플로이먼트/레플리카셋에서 `.spec.replica` 값을 삭제.. 더보기
쿠버네티스(Kubernetes) 디플로이먼트 (Deployment) 롤백 & 상태 ■ 쿠버네티스(Kubernetes) 디플로이먼트 (Deployment) 롤백 개요디플로이먼트가 지속적인 충돌로 안정적이지 않은 경우 롤백이 가능하다. 모든 디플로이먼트의 롤-아웃 기록은 시스템에 남아 있어 언제든지 롤백이 가능하다. 디플로이먼트 수정 버전은 디플로이먼트 파드 템플릿(.spec.template)이 변경되는 경우에만 새로운 수정 버전이 생성된다. 예를 들면 템플릿 레이블 또는 컨테이너 이미지와 같은 변경을 의미 한다.디플로이먼트의 버전관리는 기본적으로 10개 까지 가능하며 해당 항목은 `.spec.revisionHistoryLimit` 필드 설정을 통해 변경할 수 있으며, 0으로 설정하게 되면 디플로이먼트의 기록을 모두 초기화 하기 때문에 롤백을 할 수 없다.일시 중지된 디플로이먼트를 다시 .. 더보기
쿠버네티스(Kubernetes) 디플로이먼트 (Deployment) 생성 및 업데이트 ■ 쿠버네티스(Kubernetes) 디플로이먼트 (Deployment) 개요디플로이먼트에서 의도하는 상태를 설명하고, 디플로이먼트 컨트롤러(Controller, API 서버를 통해 K8S 클러스터를 모니터링 하고, 현재 상태를 원하는 상태로 이행 시키는 역할 수행)는 현재 상태에서 의도하는 상태로 비율을 조정하며 변경 한다. 디플로이먼트는 파드와 레플리카셋(ReplicaSet)에 대한 선언적 업데이트를 제공 한다. 선언적 업데이트란 원하는 상태를 정의하고 쿠버네티스가 이를 자동으로 달성하도록 하는 방식. 사용자는 시스템의 최종 상태를 선언하고, 쿠버네티스는 현재 상태를 이 최종 상태로 맞추기 위해 필요한 모든 작업을 수행합니다. 이를 통해 사용자는 복잡한 업데이트 절차를 직접 관리할 필요 없이, 단순히 .. 더보기
쿠버네티스(Kubernetes) 중단 (Disruption) ■ 쿠버네티스(Kubernetes) 중단 (Disruption)Pod는 일반적 상황에서는 중단되지 않음. 하지만 관리자 또는 컨트롤러의 명령으로 인한 제거 (자발적 중단) 또는 Pod가 동작하는 하드웨어적인 오류로 인한 Pod 중단(비자발적 중단)이 발생 할 수 있음.  ■ 쿠버네티스(Kubernetes) 중단 (Disruption) 종류비자발적 중단노드를 지원하는 물리 머신의 하드웨어 오류클러스터 관리자의 실수로 VM(인스턴스) 삭제클라우드 공급자 또는 하이퍼바이저의 오류로 인한 VM 장애커널 패닉클러스터 네트워크 파티션의 발생으로 클러스터에서 노드가 사라짐노드의 리소스 부족으로 파드가 축출됨비자발적 중단은 Pod Disruption Budget(PDB)로 막을 수는 없지만 Budget은 차감 됨자발적.. 더보기
쿠버네티스(Kubernetes) NameSpace CPU 자원 할당 ■ 쿠버네티스(Kubernetes) NameSpace CPU 자원쿠버네티스 CPU 할당에 사용되는 단위는 정수 또는 소수점 형태로 표기 한다. CPU 자원 할당은 노드의 타입에 따라 다르다. 물리 서버인 경우 1 물리 CPU 코어가 되고, 가상 서버일 경우 1가상 코어에 해당 함.CPU 자원이 1.0일 경우 1,000 밀리 CPU (1,000m), 0.1일 경우 100 밀리 CPU (= 100m)를 의미 한다.쿠법네티스에서는 1m 보다 더 정밀한 단위로 표기할 수 없고, 표기 방법은 0.0005 보다 5m 처럼 직관적인 방식으로 표현하는 것이 좋음. ■ 쿠버네티스(Kubernetes) NameSpace CPU 할당네임스페이스에 리소스 쿼터가 설정되어 있는 경우, CPU 상한에 기본값을 설정하는 것이 좋음.. 더보기
쿠버네티스(Kubernetes) NameSpace 메모리 자원 할당 ■ 쿠버네티스(Kubernetes) NameSpace 메모리 할당네임스페이스에 리소스 쿼터가 설정되어 있는 경우, 메모리 상한에 기본값을 설정하는 것이 좋음.리소스 쿼터가 설정 된 네임스페이스에서 실행되는 모든 컨테이너는 메모리 상한이 있어야 한다 (메모리 상한을 통해 쿠버네티스가 파드 수준 메모리 상한을 추론할 수 있음)메모리 상한은 파드가 스케줄링 될 노드에 리소스 예약을 적용함.네임스페이스의 모든 파드가 실제로 사용하고 있는 메모리 총량은 지정된 상한을 초과하지 않아야 함네임스페이스 생성  및  기본 메모리 요청/상한 설정# 네임스페이스 생성kubectl create namespace default-mem-example# 네임스페이스의 리밋레인지 (LimitRange) 정의# admin/resour.. 더보기
쿠버네티스(Kubernetes) Pod Quality of Service (QoS) ■ 쿠버네티스(Kubernetes) Pod Quality of Service (QoS) 개요QoS (Quality of Service)는 기본적으로 전체 서비스에 대한 품질을 보장하는 것이 아닌, 중요도가 높은 서비스의 품질을 보장 하는 기술을 의미한다. 쿠버네티스에서도 동일한 의미로 해당 기술을 사용하며, 노드에 충분한 가용 리소스가 없을 경우 QoS를 사용하여 Pod를 노드에서 제거하여 가용 리소스 확보를 목적으로 사용한다.Memory QoS는 Kubernetes에서 메모리 자원을 보장하기 위해 cgroup v2의 메모리 컨트롤러를 사용 함.쿠버네티스에서 기본적으로 Pod 생성 시 예외없이 QoS Class (Guaranteed, Burstable, BestEffort) 3개중 하나를 부여하여 Pod.. 더보기

반응형