일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 | 31 |
- kube
- 레이블 셀렉터
- 어플리케이션셋
- kubernetes in action
- kubernetes component
- kubenetes architecture
- 쿠버네티스 어노테이션
- 빌드
- 피터코드
- 피터코드의 상속규칙
- kubenetes in action
- 상속성
- argocd applicationset
- 캡슐화
- 객체지향
- 위임
- delegation
- 레이블
- Abstraction
- maven
- 메이븐
- OOP
- 쿠버네티스
- kubernetes
- applicationset
- kubernetes in actin
- kubenetes
- 추상화
- Encapsulation
- ArgoCD
- Today
- Total
목록Kubernetes (9)
IT 끄적장

파드 및 다른 오브젝트는 레이블 외에 어노테이션을 가질 수 있다. 어노테이션은 key-value 쌍으로 레이블과 거의 비슷하지만 식별 정보를 갖지 않는다. 레이블은 오브젝트를 묶는 데 사용할 수 있지만 어노테이션은 그렇게 할 수 없다. 같은 맥락에서 어노테이션 셀렉터 또한 존재하지 않는다. 반면 어노테이션은 훨씬 더 많은 정보를 공유할 수 있다. 특정 어노테이션은 쿠버네티스에 의해 자동으로 오브젝트에 추가되지만, 나머지 어노테이션은 사용자에 의해 수동으로 추가된다. 어노테이션은 쿠버네티스에 새로운 기능을 추가할 때 흔히 사용된다. 일반적으로 새로운 기능의 알파 혹은 베타 버전은 API 오브젝트에 새로운 필드를 바로 도입하지 않는다. 필드 대신 어노테이션을 사용하고, 필요한 API 변경이 명확해지고 쿠버네..

실제 애플리케이션을 배포할 때 대부분의 사용자는 더 많은 파드를 실행하게 될 것이다. 파드 수가 증가함에 따라 파드를 부분 집합으로 분류할 필요가 있다. 예를 들어 MSA의 경우 배포된 마이크로 서비스의 수는 매우 쉽게 20개를 초과한다. 이러한 구성요소는 복제돼(동일한 구성 요소 여러 복사본이 배포된다.) 여러 버전 혹은 릴리즈가 동시에 실행된다. 이로 인해 시스템에 수백 개의 파드가 생길 수 있다. 파드를 정리하는 메커니즘이 없다면 MSA 안에 있는 파드는 크고 이해하기 어려운 난장판이 된다. 모든 개발자와 시스템 관리자는 어떤 파드가 어떤 것인지 쉽게 알 수 있도록 임의의 기준에 따라 작은 그룹으로 조직하는 방법이 필요하다. 각 파드에 대해 개별적으로 작업을 수행하기보다 특정 그룹에 속한 모든 파드..

파드를 포함한 다른 쿠버네티스 리소스는 일반적으로 쿠버네티스 REST API 엔드포인트에 JSON 혹은 YAML 매니페스트를 전송해 생성한다. kubectl run 명령처럼 다른 간다한 방법으로 리소스를 만들 수 있지만, 제한된 속성 집합만 설정할 수 있다. 그리고 YAML 파일에 모든 쿠버네티스 오브젝트를 정의하면 버전 관리 시스템에 넣는 것이 가능해져, 그에 따른 모든 이점을 누릴 수 있다. Pod를 구성하는 주요 부분 소개 apiVersion: v1 kind: Pod metadata: name: my-app spec: containers: - image: nginx name: my-nginx ports: - containerPort: 8080 protocol: TCP 파드 정의는 몇 부분으로 구성된..

POD에서 컨테이너의 적절한 구성파드를 각각 별도의 머신으로 생각할 수 있지만, 파드는 특정한 애플리케이션만을 호스팅 한다.한 호스트에 모든 유형의 애플리케이션을 넣었던 이전과 달리, 파드는 그렇게 사용하지 않는다.파드는 상대적으로 가볍기 때문에 오버헤드 없이 필요한 만큼 파드를 가질 수 있다. 모든 것을 파드 하나에 넣는 대신에 애플리케이션을 여러 파드로 구성하고, 각 파드에는 밀접하게 관련 있는 구성 요소나 프로세스만 포함해야 한다. 다계층 애플리케이션을 여로 파드로 분할프런트엔드 서버와 DB 컨테이너 두 개로 구성된 단일 파드를 실행할지 못할 것은 없지만, 적절한 방법은 아니다. 파드의 모든 컨테이너는 항상 같은 위치에서 실행되지만, 웹 서버와 데이터베이스가 정말로 같은 머신에서 실행되어야 하는 가..

POD(파드) 소개 파드는 함께 배치된 컨테이너 그룹이며 쿠버네티스의 기본 빌딩 블록이다. 컨테이너를 개별적으로 배포하기 보다는 컨테이너를 가진 파드를 배포하고 운영한다. 여기서 파드가 항상 두개 이상의 컨테이너를 포함하는 것을 의미하는 것은 아니다. 일반적으로 파드는 하나의 컨테이너만 포함한다. 파드의 핵심은 파드가 여러 컨테이너를 가지고 있을 경우에, 모든 컨테이너는 항상 하나의 워커 노드에서 실행되며 여러 노드에 걸쳐 실행되지 않는다. POD가 필요한 이유 IPC 혹은 로컬 파일을 통해 통신하는 여러 프로세스로 구성되어 있고, 같은 노드에서 실행해야 하는 애플리케이션을 상상해보면, 쿠버네티스에서는 프로세스를 항상 컨테이너에서 실행시키고 각 컨테이너는 격리된 머신과 비슷하기 때문에 여러 프로세스를 단..

모든 서버에 쿠버네티스를 설치한 경우 운영 팀이 더 이상 애플리케이션 배포를 처리할 필요가 없다. 컨테이너화 된 애플리케이션을 배포하고 실행하기 위해 아무것도 설치할 필요가 없다. 쿠버네티스가 배포된 모든 노드에서는 시스템 관리자의 도움 없이 즉시 애플리케이션을 실행할 수 있다. 애플리케이션 배포의 단순화 쿠버네티스는 모든 워커 노드를 하나의 배포 플랫폼으로 제공하기 때문에 애플리케이션 개발자는 자체적으로 애플리케이션 배포를 시작할 수 있으며 클러스터를 구성하는 서버에 관해 알 필요가 없다. 본질적으로 모든 노드는 이제 애플리케이션이 해당 노드를 사용하기를 기다리는 하나의 컴퓨팅 리소스다. 서버는 애플리케이션에 적절한 시스템 리소스를 제공할 수 있는 한, 애플리케이션이 어느 서버에서 실행 중인지는 신경 ..