Kubenetes (35) 썸네일형 리스트형 Pod 4 - (Namespace) - 객체를 서로 겹치지 않는 별개의 그룹으로 분리하려는 경우 쿠버네티스는 객체를 네임스페이스로 그룹화 함. - 이 네임스페이스는 리눅스 네임스페이스와는 다름 - 동일한 리소스 이름을 여러 네임스페이스에서 여러 번 사용할 수 있다. [네임스페이스의 필요성] - 여러 네임스페이스를 사용하면 많은 구성 요소를 포함하는 복잡한 시스템을 더 작은 그룹으로 분할 가능 - 멀티 테넌트(multi-tenant) 환경에서 리소스를 분리하고 리소스를 생산, 개발 및 QA 환경으로 또는 기타 필요한 방식으로 분할 하는데 사용 가능 - 리소스 이름은 네임스페이스 내에서만 고유하면 됨, 두 개의 네임스페이스는 동일한 이름의 리소스 포함 가능 [다른 네임스페이스와 네임스페이스의 포드] 클러스터에 있는 모든 네임스페이스 나열 $ .. Pod 3 - (Label을 이용한 Pod 구성) [라벨 소개] - 라벨은 포드 뿐만 아니라 쿠버네티스의 모든 리소스를 구성하는 간단하면서도 강력한 쿠버네티스 기능 - 라벨은 리소스에 첨부하는 임의의 키/값 쌍이다. - 라벨 셀렉터를 사용해 리소스를 선택할 때 활용 - 리소스는 해당 라벨의 키가 해당 자원 내에서 고유한 경우 하나 이상의 라벨을 가질 수 있다. - 각각의 포드는 두개의 라벨이 있다. ㅁ app은 포드가 속한 애플리케이션이며, 구성 요소 또는 마이크로서비스를 지정한다. ㅁ rel은 포드에서 실행 중인 애플리케이션이 안정적 버전, 베타 혹은 카나리 버전인지 여부를 표시 정의: 카나리 버전은 안정적인 버전 이외의 새로운 버전의 애플리케이션을 배포할 때 사용. 모든 사용자에게 배포하기 전에 일부 사용자가 새로운 버전을 사용해 동작 방법을 살펴 .. Pod 2 - (YAML이나 JSON 파일 디스크립터에서 Pod 만들기) Pod와 그 밖의 쿠버네티스 리소느는 일반적으로 JSON 또는 YAML 매티페스트를 쿠버네티스R EST API 앤드포인트에 게시해 생성 각 리소스 유형의 모든 속성을 구성하려면 쿠버네티스 API 객체의 정의를 알아야 함. 1. Pod의 YAML 디스크립터 검사 [배포된 Pod의 전체 YAML] $ kubectl get po kubia-zxzij -o yaml apiVersion: v1 kind: Pod metadata: annotations: kubernetes.io/created-by: ... creationTimestamp: 2016-03-18T12:37:50Z generateName: kubia- labels: run: kubia name: kubia-zxzij namespace: default r.. Pod 1 - (Pod 개요) 1. Pod의 필요성 - 여러 프로세스를 실행할 때 한개의 컨테이너보다 다수의 컨테이너가 더 적합 ㅁ 컨테이너는 프로세스 자체가 하위 프로세스를 생성하지 않는 한 컨테이너당 하나의 프로세스만 실행하도록 설계 ㅁ 다양한 프로세스들이 상호 관리를 통해 지원하는 환경을 구성할 경우(Web Process, Log 저장용 프로세스, Scheduling 프로세스 등) 하나의 컨테이너에서 수행이 어려울 수 있다. 2. Pod - 여러 개의 프로세스를 하나의 컨테이너로 묶으면 안 되기 때문에 컨테이너를 단일 단위로 관리할 수 있는 상위 레벨 구조가 필요 [동일한 포드의 컨테이너 사이의 부분 격리] - 쿠버네티스는 도커를 구성하여 각 컨테이너가 자체 세트를 가지고 있는 대신 모든 Pod Container가 동일한 Lin.. 볼륨: PersistentVolume과 PersistentVolumeClaim ㅁ 기본 스토리지 기술에서 포드 분리 [PersistentVolume] 과 [PersistentVolumeClaim] [PersistentVolume 생성] mongodb-pv-gcepd.yaml apiVersion: v1 kind: PersistentVolume metadata: name: mongodb-pv spec: capacity: #PersistentVolume 크기 정의 storage: 1Gi accessModes: #단일 클라이언트가 읽기 및 쓰기 용으로 마운트하거나 여러 클라이언트가 읽기 전용으로 마운트할 수 있다. - ReadWriteOnce - ReadOnlyMany persistentVolumeReclaimPolicy: Retail # 클레임이 해제된 후에는 PersistentVolu.. 볼륨: 컨테이너에 디스크 스토리지 연결 쿠버네티스의 볼륨은 Pod의 컴포넌트이므로 컨테이너와 마찬가지로 Pod의 스펙에 정의 볼륨은 독립적인 쿠버네티스 오브젝트가 아니며 스스로 생성하거나 삭제할 수 없다. ㅁ 사용 가능한 볼륨 유형 - emptyDir: 일시적인 데이터를 저장하는 데 사용되는 비어있는 다순한 디렉터리 - hostPath: 워커노드의 파일 시스템에서 Pod로 디렉터리를 마운트하는 데 사용 - gitRepo: Git 스토리지의 내용을 체크아웃해 초기화된 볼륨 - nfs: Pod에 마운트된 NFS 공유 - gcePersistentDisk(구글 컴퓨트 엔진 영구 디스크), awsElastic-BlockStore(AWS EBS), azureDisk(마이크로소프트 애저 디스크 볼륨): 클라우드 제공자에 따라 전용 스토리지를 마운트하는데 .. 외부 서비스에서 외부 클라이언트로...(Nodeport, Loadbalancer, Ingress) [서비스가 외부에서 액세스 가능하게 하는 방법] ㅇ. NodePort 서비스 타입으로 설정하기 - NodePort 서비스의 각 클러스터 노드는 노드 자체 이름을 통해 port를 열고 port에서 발생한 트래픽을 서비스로 Redirect함. ㅇ. LoadBalancer 서비스 타입으로 설정 하기 - Kubenetes가 실행 중인 클라우드 인프라스트럭처에 provision된 지정된 LoadBalancer를 통해 서비스 액세스 가능 ㅇ. Ingrea Resource 생성하기 - HTTP fpqpf(네트워크 7계층) 수준에서 동작하기 때문에 4계층 서비스보다 좀 더 기능을 제공 1. NodePort 서비스 ㅁ NodePort 서비스 생성 apiVersion: v1 kind: Service metadata: na.. 외부 서비스에 연결 (Endpoint) ㅁ 서비스 Endpoint Service는 Pod를 직접 link하지 않는다. 대신 Endpoint라 불리는 리소스가 Pod와 Service 사이에 위치 한다. $ kubectl describe svc kubia 와 같은 describe 명으로 서비스 확인 가능 get endpoints로 endpoint 정보 확인 가능 $ kubectl get endpoints kubia ㅁ 수동으로 Endpoint 설정 - Selector 없이 Service 생성 apiVersion: v1 kind: Service metadata: name: external-service spec: ports: - ports: 80 80으로 들어오는 연결을 처리하는 external-service를 정의 - Selector없이 Serv.. 이전 1 2 3 4 5 다음
