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

사용 목적 ApplicationSet 컨트롤러의 초기 설계 초점은 인프라 팀의 Kubernetes 클러스터 관리자가 수많은 클러스터에 걸쳐 크고 다양한 Argo CD 애플리케이션들을 자동으로 생성하고 이러한 애플리케이션을 단일 단위로 관리할수 있도록 한다. 한 회사 내에서는 수백~ 수천개의 개발팀 클러스터들이 존재하고 이에따른 개발 phase가 존재한다. dev - 실제 개발자들이 배포하고 기능테스트 하는 phase sandbox(QA) - 검수 단계 staging - 인하우스 릴리즈 production - 운영 신규 클러스터를 구축할때 인프라팀은 다양한 트러블 슈팅에 대응하기 위해 본인들이 담당하고 있는 서비스들의 버전을 일원화하여 동일한 인프라환경을 유지하는게 원칙으로 한다. (실제 인프라 팀에서 관..

파드 및 다른 오브젝트는 레이블 외에 어노테이션을 가질 수 있다. 어노테이션은 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 혹은 로컬 파일을 통해 통신하는 여러 프로세스로 구성되어 있고, 같은 노드에서 실행해야 하는 애플리케이션을 상상해보면, 쿠버네티스에서는 프로세스를 항상 컨테이너에서 실행시키고 각 컨테이너는 격리된 머신과 비슷하기 때문에 여러 프로세스를 단..