
Deployment - Controller인 ReplicaSet을 제어해주는 부모 역할을 한다. - Deployment는 Rolling Update를 목적으로 만들어졌다. - Deployment를 만들면 Deployment가 ReplicaSet을 만든다. 이때 Deployment는 실행시킬 Pod의 버전과 replicas를 ReplicaSet에게 전달한다. 그 후엔 ReplicaSet이 전달받은 정보를 기반으로 Pod를 생성하고 Pod 수를 보장하게 된다. - 즉, Deployment가 ReplicaSet을 컨트롤하고 ReplicaSet이 Pod를 컨트롤하는 구조이다. - 정리하자면, Deployment는 ReplicaSet Controller를 관리해서 Pod 수를 보장하고, 추가적으로 Rolling ..

ReplicaSet Controller - RC(ReplicationController)와 같은 역할을 하는 컨트롤러이다. - RC보다 다양한 형태의 selector를 지원한다. 이때 selector 필드 아래 matchLabels, matchExpressions 필드를 사용한다. - matchLabels만 사용하면 RC와 같다. (label에 대한 AND 연산) - matchExpressions까지 사용하면 다양한 형태로 표현할 수 있다. - RC, RS 모두 label과 selector 만을 기반으로 Pod를 컨트롤한다. 즉, 어떤 컨테이너인지는 관여하지 않는다. RC vs RS Definition 비교 출처: https://github.com/237summit/Getting-Start-Kuberne..

이번 포스팅에서는 쿠버네티스의 컨트롤러 중에서 ReplicationController에 대해 다룬다. ReplicationController - 요구하는 Pod의 개수를 보장하는 가장 기본적인 컨트롤러 역할을 한다. - 요구하는 Pod 개수가 부족하면 template을 이용해 Pod를 추가한다. - 요구하는 Pod 수보다 많으면 최근에 생성된 Pod를 삭제한다. ReplicationController의 기본 구성 - selector - replicas - template RC Definition 예시 - label은 key:value 형태로 정의된다. - selector에서 정의한 :와 같은 label을 가진 Pod를 replicas 만큼 운영한다. - 컨트롤러는 현재 운영되고 있는 Pod들을 모니터링하..

Controller란? 공식문서에 따르면 쿠버네티스에서 컨트롤러는 클러스터의 상태를 관찰 한 다음, 필요한 경우에 생성 또는 변경을 요청하는 '컨트롤 루프'이다. 그렇다면 컨트롤 루프(Control Loop)란 무엇인가? 컨트롤 루프(Control Loop) - 컨트롤 루프는 쿠버네티스에서만 사용되는 용어는 아니며 공식문서에 따르면 컨트롤 루프란 종료되지 않으면서 시스템 상태를 조절하는 루프라고 한다. - 컨트롤 루프는 컨트롤러를 실행시킨다. - 컨트롤 루프는 크게 3가지 행위를 한다. (모니터링, 상태 차이 발견, 액션) - 3가지 행위를 통해 '현재 상태를 의도한 상태와 같아지도록 만드는 역할'을 한다. 예시 'kubectl create deployment web-pod --image=nginx --..

컨테이너 리소스 할당 개론 - 쿠버네티스가 관리하는 리소스는 CPU와 Memory이다. - 기본적으로 컨테이너 단위로 리소스를 제한한다. 리소스를 제한하지 않을 경우 발생할 수 있는 문제 1) starvation 리소스를 제한하지 않으면 해당 노드에 할당된 컨테이너는 노드의 리소스를 전부 다 사용할 수 있다. 따라서 만약 리소스 제한을 두지 않고 특정 호스트에 Pod를 두 개 이상 띄웠을 경우, 하나의 Pod가 노드의 모든 리소스를 사용한다면 새로운 Pod가 스케줄링될 수 없다. 2) 보안 관련 이슈 만약 특정 Pod에 보안 관련 버그가 발생해서 해커가 해당 Pod에 디도스 공격을 주어 노드의 모든 리소스를 사용하게 된다면, 다른 Pod들은 스케줄링될 수 없다. ** 따라서 Pod 하나를 띄우더라도 해당..

쿠버네티스가 제공해주는 기능 10가지 쿠버네티스 공식 사이트에 들어가면 쿠버네티스가 제공해주는 10가지 기능에 대해 설명되어 있다. 이중에서도 자가 치유(Self-healing)에 대한 부분을 이번 포스팅에서 다루도록 한다. 자가 치유(Self-healing) 오류가 발생한 컨테이너를 재시작하고, 노드가 죽었을 때 컨테이너를 교체하기 위해 다시 스케줄 하고, 사용자 정의 상태 체크에 응답하지 않는 컨테이너를 제거하며, 서비스를 제공할 준비가 될 때까지 클라이언트에 해당 컨테이너를 알리지 않는다. 즉, 정상적인 컨테이너들만을 대상으로 애플리케이션을 운영해 주겠다는 의미이다. Self-handling 기능중에 포함된 것이 'livenessProbe'이다. livenessProbe는 컨테이너를 진단해서 정상적..

쿠버네티스에서 컨테이너 동작 flow 새로운 컨테이너를 실행시키는 flow 1) kube-apiserver는 REST API Server로서 kubectl 커맨드나 yaml로 작성된 파일의 요청을 받고 처리한다. api-server는 우선 etcd에서 worker노드들의 상태 정보를 수집한 뒤 scheduler로 보낸다. 2) scheduler는 api-server로부터 요청을 받고 worker 노드의 상태를 확인한 뒤 어느 노드에 배치시키는 것이 가장 좋을지 결정 후 api-server로 응답한다. 3) api-server가 응답을 받고 해당하는 노드로 컨테이너 배치를 요청한다. 이때 해당 worker노드의 kubelet으로 요청을 보낸다. 4) worker노드의 kubelet이 컨테이너 런타임으로 요..

cf. 설치할 버전 containerd 1.5.5 runC 1.1.1 * contianerd 및 runC는 컨테이너 동장을 위해 필요하기 때문에 쿠버네티스 클러스터 시작(kubeadm init) 전에 반드시 필요함. * CNI 플러그인은 Pod CIDR 및 서브넷을 구성하기 때문에 kubeadm init 전 또는 후에 필요함. * CNI 플러그인이 설치되지 않은 경우 CoreDNS가 제대로 동작할 수 없음. 1. containerd 1.5.5 설치 쿠버네티스 버전 1.22를 사용할 것이기 때문에 containerd는 1.5.5를 사용한다. 링크: https://www.itzgeek.com/how-tos/linux/ubuntu-how-tos/install-containerd-on-ubuntu-22-04.h..
- Total
- Today
- Yesterday
- Non-Blocking
- db
- github actions
- 코틀린
- RDB
- CICD
- LFCS
- Java
- Controller
- go
- Stream
- kafka
- rolling update
- 카프카
- K8s
- argocd
- 쿠버네티스
- container
- helm
- golang
- spring
- 우분투
- docker
- 컨트롤러
- ubuntu
- GitOps
- Linux
- ci/cd
- jvm
- Kubernetes
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 |