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들을 모니터링하..
컨테이너 리소스 할당 개론 - 쿠버네티스가 관리하는 리소스는 CPU와 Memory이다. - 기본적으로 컨테이너 단위로 리소스를 제한한다. 리소스를 제한하지 않을 경우 발생할 수 있는 문제 1) starvation 리소스를 제한하지 않으면 해당 노드에 할당된 컨테이너는 노드의 리소스를 전부 다 사용할 수 있다. 따라서 만약 리소스 제한을 두지 않고 특정 호스트에 Pod를 두 개 이상 띄웠을 경우, 하나의 Pod가 노드의 모든 리소스를 사용한다면 새로운 Pod가 스케줄링될 수 없다. 2) 보안 관련 이슈 만약 특정 Pod에 보안 관련 버그가 발생해서 해커가 해당 Pod에 디도스 공격을 주어 노드의 모든 리소스를 사용하게 된다면, 다른 Pod들은 스케줄링될 수 없다. ** 따라서 Pod 하나를 띄우더라도 해당..
쿠버네티스가 제공해주는 기능 10가지 쿠버네티스 공식 사이트에 들어가면 쿠버네티스가 제공해주는 10가지 기능에 대해 설명되어 있다. 이중에서도 자가 치유(Self-healing)에 대한 부분을 이번 포스팅에서 다루도록 한다. 자가 치유(Self-healing) 오류가 발생한 컨테이너를 재시작하고, 노드가 죽었을 때 컨테이너를 교체하기 위해 다시 스케줄 하고, 사용자 정의 상태 체크에 응답하지 않는 컨테이너를 제거하며, 서비스를 제공할 준비가 될 때까지 클라이언트에 해당 컨테이너를 알리지 않는다. 즉, 정상적인 컨테이너들만을 대상으로 애플리케이션을 운영해 주겠다는 의미이다. Self-handling 기능중에 포함된 것이 'livenessProbe'이다. livenessProbe는 컨테이너를 진단해서 정상적..
VM, 컨테이너, 멀티호스트 컨테이너 플랫폼, 컨테이너 오케스트레이션까지의 발전과정에 대한 포스팅이다. '가상화' 개념의 등장 가상화 개념이 처음 등장했던 1960년대에, 무어의 법칙에 의해 HW의 성능이 빠르게 발전하는데 SW는 이만큼 발전을 하지 못했던 상황이 발생했다. 즉, HW는 빠르게 발전하는데 SW가 이를 제대로 활용하지 못하는 상황이 발생한 것이다. 또한 그 당시 컴퓨터 HW 자원의 가격은 매우 비싼 편이었다. 여러 대의 비싼 컴퓨터를 사용해서 애플리케이션을 띄우는 것은 매우 비효율적이라는 문제가 있었던 것이다. 이러한 문제점을 해결하고자 등장한 것이 '가상화'이다. 한 대의 컴퓨터의 자원을 가상화해 여러 대인 것처럼 보이게 하자는 것이다. 하나의 물리적인 컴퓨터 위에 여러 대의 OS가 구동..
Microservice - 기존 모놀리틱 구조에서 모든 도메인과 기능이 하나의 시스템에 담겨있고 서비스가 방대해짐에 따라 복잡성이 커졌다. - Microservice는 기존 모놀리틱 구조에서 방대한 시스템을 적절하게 나눈 구조로 설명된다. - 'API Gateway'를 두고 기능별/도메인별로 요청이 '분기'하도록 구성된다. 특징 [장점] - 기존 모놀리틱 구조에서는 장애 발생 시 서비스 전체가 마비될 것이다. Microservice는 분리한 서비스 단위로 배포가 가능하기 때문에 자유롭게, 가볍게 배포가 가능하며 확장도 용이하다.(서비스 간 의존도가 떨어지기 때문) - 애플리케이션 재기동 시간이 크게 단축된다. (보통 모놀리틱은 한번 빌드하는데 엄청난 시간이 소요) - 다른 서비스와는 API로 연동되기 때..
- Total
- Today
- Yesterday
- db
- 컨트롤러
- Java
- 쿠버네티스
- LFCS
- Controller
- helm
- Non-Blocking
- spring
- 카프카
- docker
- Linux
- container
- 코틀린
- Stream
- RDB
- CICD
- 우분투
- github actions
- argocd
- golang
- Kubernetes
- kafka
- ubuntu
- rolling update
- GitOps
- ci/cd
- go
- jvm
- K8s
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |