클라우드 활용 네트워크 엔지니어 부트캠프

1. DaemonSet지속적으로 돌아야 하는 어떤 프로세스를 실행하고 싶을 때 사용하는 워크로드 리소스 지속적으로 모니터링을 하고, PV / PVC를 붙여서 데이터를 저장해야 할 때 사용노드가 추가되거나 제거되더라도 자동으로 해당 노드에 파드가 배포되거나 삭제됨모든 서버에서 동일하게 작업되어야 하는 기준을 가지고 있다면 데몬셋이 가장 적당함일반적으로 모든 노드에 하나씩 실행해 spec.replicas 필드가 필요하지 않음 1) DaemonSet vs Static Pod비교 항목 DaemonSet Static Pod 생성 방식YAML로 생성, kubectl로 관리 가능노드의 로컬 파일(/etc/kubernetes/manifests/)에 직접 배치관리 주체Kubernetes API ServerKubelet..

1. [실습] 각각의 프로브를 사용한 livenessProbe 구성해보기 쿠버네티스에서 livenessProbe는 컨테이너가 정상적으로 동작 중인지 여부를 주기적으로 확인하여 비정상일 경우 자동으로 재시작해주는 메커니즘이다. 이 실습에서는 exec 프로브를 활용하여 /tmp/healthy 파일 존재 여부를 기준으로 헬스 체크를 수행한다. 파라미터 종류initialDelaySeconds : 컨테이너 시작 후 헬스체크까지 대기 시간periodSeconds : 헬스 체크 주기timeoutSeconds : 헬스체크 명령 실행 제한 시간successThreshold : n회 이상 성공하면 정상으로 간주failureThreshold : n회 연속 실패시 비정상으로 간주하고 컨테이너 재시작 트리거 됨 # vi exe..

1. Pod1) Pod란Pod는 쿠버네티스에서 사용하는 가장 작은 배포 단위이자 컴퓨팅 단위로, 내부에 하나 이상의 컨테이너를 포함할 수 있다. 일반적으로는 하나의 Pod에 하나의 컨테이너를 실행하는 것이 권장되지만, 밀접하게 연관된 프로세스를 함께 실행해야 할 경우 복수의 컨테이너를 하나의 Pod 안에 둘 수도 있다. 2) Pod의 특징고유 IP 할당: 각 Pod는 고유의 IP 주소를 가지며, Pod내부의 컨테이너 간 통신은 localhost를 통해 포트 기반으로 이루어짐단일 노드 배포: 하나의 Pod는 반드시 하나의 노드에만 배포된다. Pod 내 컨테이너는 해당 노드에 같이 올라감컨테이너 배포 단위: 쿠버네티스에서 컨테이너를 직접 다루지 않고, Pod 단위로 컨테이너를 관리하고 배포 3) Pod의 장..

1. 쿠버네티스 아키텍처1) 기본 구성 2) Control Plane의 작동 흐름사용자가 kubectl로 명령 전송→ API Server에 HTTP 요청을 보냄API Server가 요청을 수신하고 etcd에 클러스터 상태 업데이트Scheduler가 새로 생성된 Pod에 대해 적절한 Node를 선택선택된 Node의 kubelet이 해당 Pod를 생성하고 컨테이너 실행kube-proxy가 서비스 네트워크 연결 경로를 설정하고, 클러스터 내부 트래픽을 관리 3) 상태 확인 4) 명령어 shortnames가 설정되어 있는 경우 약어로 짧게 사용 가능하다.더 자세한 명령어를 보려면 해당 사이트 방문 -> https://kubernetes.io/ko/docs/reference/kubectl/ 명령줄 도구 (ku..

1. Podman Volume컨테이너에서 볼륨은 데이터를 저장하기 위한 용도로 사용한다.Podman Image: 읽기 전용 (Read-Only)Podman Container: 읽기/쓰기 가능 (Read-Write)컨테이너의 파일 시스템은 휘발성이므로, 데이터 유지에는 볼륨이 필수 1) 마운트 방식유형 설명Bind Mount호스트 PC의 특정 디렉토리를 컨테이너 내부에 마운트Named Volume (익명/이름있는 볼륨)Docker가 관리하는 영역에 자동 생성됨Shared Volume컨테이너 간 볼륨 공유, 하지만 보통 1:1 사용이 일반적 2. Podman Network 1) 타입네트워크 타입 설명bridge기본값. NAT 기반 브릿지 네트워크. 외부와 통신 가능host컨테이너가 호스트의 네트워크 스..

1. Podman 명령어1) 이미지 관리 명령어podman images [options] : 현재 사용할 수 있는 이미지 이름 확인REPOSITORY : 등록되어 있는 실제 이름. 리포지토리 사이트 / 네임스페이스 / 이미지 이름으로 구성TAG : 태그 IMAGE ID : 이미지를 생성할 때 자동으로 부여되는 IDCREATED : 이미지가 생성된 시기SIZE : 이미지 사이즈. 하나의 파일이 아닌 base image 위에 여러개의 추가 구성요소로 구성 podman rmi [-f] :: 이미지 삭제. -f로 강제 삭제 가능 podman push //:: 이미지 push podman pull [options] //:: 특정 원격 레지스트리에서 이미지 가져오기 podman history [options] ..

1. Docker컨테이너 기반의 오픈소스 가상화 플랫폼 가상머신처럼 독립적으로 실행되지만 가상머신보다 빠르고 쉬우며 효율적컨테이너라는 격리된 환경에서 작동하는 프로세스 단위로 실행1) VM vs Docker항목 Virtual Machine Docker 실행 구조Hypervisor + Guest OSDocker Engine운영체제Guest OS 필요Host OS 공유성능하드웨어를 깊게 활용 가능가볍고 빠름사용 목적강한 격리, 복잡한 OS 환경빠른 배포, 일관된 환경 제공 2) 도커의 특징확장성/이식성 : 도커가 설치되어 있다면 어디서든 컨테이너 실행이 가능표준성 : 컨테이너라는 표준으로 서버를 배포하므로 모든 서비스들의 배포 과정이 동일이미지 : 빌드 서버에서 Dockerfile로 이미지를 만들어 이미..

1. 느슨한 결합 전략1) 모범 사례 : 서버가 아니라 서비스를 설계웹서버는 데이터를 로컬이 아닌 외부 저장소(NFS/NAS 등)에 저장정적 웹 자산은 S3 같은 외부 저장소에 저장사용자 인증 및 상태 저장은 AWS 관리형 서비스 활용하나의 서버에는 하나의 애플리케이션만 실행하는 것이 원칙서버리스 환경에서는 필요 시 자동 프로비저닝애플리케이션 간 통신은 메시지 대기열 사용→ 서버에서 서비스 단위로 전환하면서 서버 관리 부담을 줄임 💡 서버리스의 정확한 의미서버가 없다는 의미가 아니라 서버 인프라를 직접 관리하지 않아도 되는 컴퓨팅 모델을 의미한다. 2) 서비스 지향 아키텍처(SOA) 구현구성 요소들이 통신 프로토콜로 서비스를 주고받는 구조때로는 불필요한 정보가 제공되기도 함 (뒤에서 활용됨)전통적인 모..

1. AWS 글로벌 인프라1) AWS 데이터 센터단일 데이터 센터에 수천 개의 서버 운영모든 데이터 센터는 온라인으로 연결됨Amazon 사용자 정의 네트워크 장비 및 프로토콜 스택 사용 : 아마존이 직접 설계한 맞춤형 하드웨어와 소프트웨어 스택으로 구성다양한 ODM(Original Design Manufacturer) 기반 하드웨어 채택 2) 가용 영역 (Availability Zone, AZ)하나 이상의 데이터 센터로 구성결함 격리 설계: 하나가 장애 나도 나머지는 정상 운영고속 프라이빗 링크를 통해 다른 AZ와 상호 연결사용자가 AZ 선택 가능복원력 확보를 위해 여러 AZ에 걸쳐 배포 권장일반적으로 리전당 2개 AZ 권장3개 이상 AZ 사용 시 비용 효율성 저하 가능 3) 리전 (Region)각 리전..

1. KVM 기본 이론1) KVM (Kernel-based Virtual Machine)KVM은 리눅스 커널을 하이퍼바이저로 전환하는 가상화 인프라서버에 직접 하이퍼바이저를 설치하는 방2007년부터 Linux 커널 메인라인에 포함되었으며, 완전한 가상화(Full Virtualization)를 지원VM은 Linux 프로세스로 동작하며, 커널 스케줄러의 제어를 받음Linux 커널 기능을 그대로 활용 (메모리 관리, 스케줄링, 보안 등)x86 가상화 확장 기능(Intel VT-x, AMD-V)이 있는 CPU에서 동작MAC(Mandatory Access Control) 정책 적용 가능 (ex. SELinux)VM도 리눅스 프로레스처럼 관리되어 기존 리눅스 도구로 모니터링 가능모든 Linux 지원 스토리지 사용 ..