칼의 치치

기본적인 환경 변수 사용 환경변수는 컨테이너 내에서 설정되는 간단한 키-값 쌍으로, 애플리케이션의 동작을 조정하는 데 유용 apiVersion: v1 kind: Pod metadata: name: my-pod spec: containers: - name: my-container image: my-app-image env: - name: ENV_VARIABLE_1 value: "value1" - name: ENV_VARIABLE_2 value: "value2" 위와 같이 ENV_VARIABLE_1 : "value1" 등의 값을 정적 설정을 통해서 사용 가능 kubectl exec -it sample-env --env | grep ENV_VARIABLE_1 으로 확인 가능함 아래와 같이 타임존에 대해서 UT..

* 클라이언트 : 얀으로 실행할 잡을 summit 하는 프로그램 * 잡 : 하나이상의 태스크를 포함하는 애플리케이션 * 태스크 : 맵퍼와 리듀스가 수행한 작업들 * 맵퍼와 리듀스는 각 컨테이너 내에서 동작 YARN(Yet Another Resource Negotiator) 서비스 : HDFS처럼 마스터 노드와 워커 노드 양쪽에서 모두 동작하는 서비스 리소스 관리와 작업 스케줄링을 담당하는 프레임워크 컨테이너 (Container): 컨테이너는 어플리케이션의 실행 환경을 캡슐화하는 단위입니다. 컨테이너는 작업 실행에 필요한 리소스(메모리, CPU 등)를 가지고 있으며, 노드매니저에 의해 제어됩니다. 각 앱마스터는 리소스매니저로부터 할당받은 컨테이너를 이용하여 작업을 실행합니다. 리소스매니저 (Resource..

마스터 노드와 워커(slave) 노드 마스터 노드 : 클러스터의 작업을 중재, 클라이언트들이 실제로 컴퓨팅을 하기 위해 접속하는 노드 , 3~6개 정도로 구성 네임노드 (NameNode): 마스터 노드 중 하나는 네임노드로 역할을 수행합니다. 네임노드는 메타데이터를 관리하고, 데이터 블록의 위치를 추적합니다. 클라이언트 요청에 대한 응답으로 데이터 블록을 검색하고 조정하여 데이터의 신뢰성과 가용성을 제공합니다. 잡 트래커 (JobTracker): 마스터 노드의 다른 주요 구성 요소는 잡 트래커입니다. 잡 트래커는 사용자가 제출한 작업을 관리하고 클러스터 내의 워커 노드에 할당하여 작업을 실행합니다. 작업의 진행 상황을 모니터링하고 실패한 작업을 다시 할당하여 장애 복구를 수행합니다. 보조 네임노드 (Se..

DFS 하둡의 분산 파일 시스템(Distributed File System, DFS)은 하둡 에코시스템의 핵심 구성 요소 중 하나로써 DFS는 대량의 데이터를 분산 저장하고 처리하기 위한 분산 파일 시스템. DFS는 데이터를 블록(Block) 단위로 분할하여 여러 대의 컴퓨터에 저장하며, 이를 통해 데이터의 안정성과 처리 성능을 향상. 각각의 블록은 여러 개의 노드에 복제될 수 있으며, 이는 데이터의 가용성과 장애 복구를 보장하는데 유용함. DFS의 구성 요소 네임노드(NameNode): 네임노드는 DFS의 중앙 관리자로서 메타데이터 정보를 유지합니다. 이 정보에는 파일과 블록의 위치, 권한 및 기타 속성이 포함됩니다. 또한 클라이언트 요청을 처리하고 데이터 블록의 위치 정보를 제공합니다. 데이터노드(D..

기본 개념 디플로이먼트는 여러 레플리카셋을관리하여 롤링업데이트나 롤백등을 구현하는 리소스 디플로이먼트> 레플리카> 파드 순으로 관리 1) 신규 레플리카셋을 생성 2) 신규 레플리카셋의 레플리카 수를 단계적으로 늘림 3) 이전 레플리카셋의 레플리카 수를 단계적으로 줄임 2,3 반복 이전 레플리카 셋은 레플리카수를 0으로 유지 * 안정적인 파드 기동 방법으로 추천됨 - 파드 장애시 자동으로 파드 재생성 - 레플리카만으로 배포할 경우 롤링 업데이트 등의 기능을 사용할 수 없음 디플로이먼트가 업데이트(레플리카셋이 생성되는) 되는 조건 레플리카 수 등의 변경등은 업데이트 되지 않는다 실질적으로 파드의 내용 변경이 필요함 즉 레플리카 spec.template의 내용이 변경되어야 실제로 업데이트된다. (spec.te..

레플리카셋 - 파드에 레플리카를 생성하고 지정한 파드수를 유지하는 리소스 - 노드나 파드에 장애가 발생했을 때 지정한 파드 수를 유지하기 위해 다른 노드에서 파드를 기동시켜 주기 때문에 장애 시에도 많은 영향을 받지 않음 (high Availability, LoadBalance를 수행함) - 모니터링은 특정 레이블을 가진 파드 수를 계산하는 형태로 이루어짐 (yaml 형식) - template에 명시된 형태로 pod를 자동 생성함 - replicas로 유지할 pod의 숫자를 정함 - 특정 레이블을 가진 레플리카 수가 부족한 경우 매니 페스트에 기술된 spec.template으로 파드를 생성하고 수가 많을 경우 해당 레이블을 가진 파드 중에서 하나를 삭제함 ( 따라서 해당 모니터링을 위해 selector...

KubeConfig 인증서를 통한 쿠버네티스 API 서버에 대한 접근을 구성파일을 통해 명시하고 사용하는 방식 * 아래와 같이 kubectl 명령어를 통해서 사용하던 방식을 파일로 저장 * KubeConfig 파일은 명시하지 않을시에 쿠버네티스의 디폴트 위치에 있는 파일을 사용하기 때문에 따로 명시하지 않아도 사용 * /root/.kube/config에 존재 KubeConfig File 구성요소 1. Clusters : 개발환경 , 배포환경 등 쿠버네티스 기본 환경에 관한 내용 2. Users : 유저에 대한 정보 , 구분 ,인증 정보 3. Contexts : Users와 Clusters에 대한 정보를 연결해주는 Context 정보 생성 예시 apiVersion: v1 kind: Config cluste..

쿠버네티스는 모든 파드는 노드네임이 존재하나 노드네임을 직접 명시 하지 않으면 랭킹 알고리즘을 통해 적절한 노드에 파드를 생성한다. 스케줄러는 생성할 적절한 노드를 선택하고 파드들의 상태를 확인한다. - kubectl get pods -n kube-system NAME READY STATUS RESTARTS AGE coredns-78fcd69978-5x8np 1/1 Running 0 14d coredns-78fcd69978-fsffz 1/1 Running 0 14d etcd-docker-desktop 1/1 Running 0 14d kube-apiserver-docker-desktop 1/1 Running 0 14d kube-controller-manager-docker-desktop 1/1 Runnin..

pod, deployment, service를 내부적인 목적에 따라서 세트로 묶어서 구분함 쿠버네티스는 시작할때 3가지 네임스페이를 만듦 default: 초기 기본 네임스페이스 kube-system: network나 dns를 위해 사용자들에서 분리해 낸 네임스페이스를 만듦, 실수로 삭제, 수정할 수 없도록 만듦 kube-public: 모든 유저가 사용하는 리소스들을 관리하는 네임스페이스 각 네임스페이스별로 사용할 수 있는 리소스의 양을 정해두고 사용할 수 있음 네임스페이스 안에서는 name으로 각 파드들을 호출할 수 있음 다른 네임스페이스에 존재하는 파드들은 '서비스네임.네임스페이이스.(서비스,파드등 구분).도메인'으로 구분함 ex)db-service.dev.svc.cluster.local kubectl..

- 서비스 애플리케이션의 다양한 구성요소에서의 통신을 위해 사용함 내부의 모든 파드들 간의 연결뿐만 아니라 클러스터 외부와의 연결도 담당함 1. NodePort 쿠버네티스 노드의 ip (192.168.1.2)이고 노드 내부의 파드의 ip는 10.244.0.2인상태에서 외부(192.169.1.10)가 파드에 접속하는 방법 파드의 80 포트(targetPort)를 서비스(10.106.1.12)의 80(port)으로 연결하고 해당 서비스를 노드의 특정포트(nodePort, 30000~32767)에 연결하여 사용함 apiVersion : v1 kind : Servcie metatdata : name: myapp-service spec: type: NodePort ports: - targetPort:80 port..