칼의 치치

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..

1. etcd (자세한 설명 : https://tech.kakao.com/2021/12/20/kubernetes-etcd/) 쿠버네티스는 Key-Value형태로 데이터 저장 고가용성 Key-Value 자료구조 ETCD control client로 cli를 통해 서버에 대한 정보를 키-밸류 값으로 가져올 수 있음 쿠버네티스가 ETCD를 활용하여 클러스터에 관한 정보를 저장함 (노트,포드,시크릿) 클러스터에서 어떤 정보를 수정 변경할 때마다 etcd에 저장됨 kube -system 조회를 통해 etcd-master를 확인할 수 있음 마스터 노드에서 확인 가능 다중 마스터 클러스터에서는 각 etcd 서버가 서로를 연결하도록 구성 2. kube-api-server kubectl 명령어로 입력하면 kube-api..

1 . Angular.json - 기본 프로젝트 프로퍼티 (아이콘 ,이름) 설정 2 package.json - 실행 환경 설정(실행 옵션) 3-1. main.ts import { platformBrowserDynamic } from '@angular/platform-browser-dynamic'; import { AppModule } from './app/app.module'; platformBrowserDynamic().bootstrapModule(AppModule) .catch(err => console.error(err)); 시작 지점 , AppModule(app.module.ts에 존재) 실행 3-2. index.html 시작 화, body에서 라는 컴포넌트를 호출함 4-1. app.module...

1. docker-compose.yml 생성 version: '2' services: zookeeper1: image: confluentinc/cp-zookeeper:latest environment: ZOOKEEPER_SERVER_ID: 1 ZOOKEEPER_CLIENT_PORT: 2181 ZOOKEEPER_TICK_TIME: 2000 ZOOKEEPER_INIT_LIMIT: 5 ZOOKEEPER_SYNC_LIMIT: 2 ports: - "22181:2181" kafka1: image: confluentinc/cp-kafka:latest depends_on: - zookeeper1 ports: - "29092:29092" environment: KAFKA_BROKER_ID: 1 KAFKA_ZOOKEEPE..