chris3471 님의 블로그

노드 관리1) Cordon- 노드를 "신규 파드 배치 금지 상태"로 만드는 것 - 해당 노드에 새로운 파드가 더 이상 스케줄되지 않도록 함 - 기존 파드는 그대로 실행 중(죽지 않음) - 주 용도는 노드 점검 / 유지보수 전 임시 차단 2) Uncordon - Cordon 상태를 해제하는 것 - 해당 노드에 다시 새로운 파드가 스케줄 가능하도록 함 - 주 용도는 점검 완료 후 정상 복귀 실습1) Cordon / Uncordon이 "새 파드 스케줄링"에 어떤 영향을 주는지 확인하는 실습 1. Node 상태 확인 (kubectl get nodes)- 클러스터 구성 - jhw-cluster1 : control-plane - jhw-cluster2~4 : worker 노드- 모든 노드가 ..

Volume- 쿠버네티스에서 Pod는 기본적으로 휘발성- Pod가 재시작/삭제되면 컨테이너 내부 데이터도 함께 사라짐 => 데이터를 Pod 수명과 분리해서 안전하게 저장하기 위해 Volume을 사용 Volume Type 1) 임시 디스크 - Pod가 생성될 때 같이 생성되고 Pod가 삭제되면 데이터도 함께 삭제2) 로컬 디스크 - Pod가 배포된 노드에 저장소를 만들어서 그 로컬 저장소로 사용3) 네트워크 디스크 - 각 CSP마다(클라우드사) 외부 스토리지를 사용할 수 있음 (동적 외부 스토리지를 만들어서 실습할 예정) 속성1) Capacity - 볼륨의 최대 저장 용량2) VolumeMode - 파일시스템과 Block을 설정 (Filesystem은 Volume이 Pod의 디렉토리로 마운트, Block..

01. MSA 개발 원칙 (12 Factors)- MSA 개발 원칙 = 12 Factors- 이 12가지는 실제로 거의 "표준"처럼 취급- Cloud Native, 특히 Kubernetes 환경과 매우 밀접하게 같이 쓰이는 원칙임 기본 베이스라인- 모든 MSA는 Container단위로 운영- 각 서비스는 배포되면 Pod 형태로 올라감- 서비스 간 연동은 HTTP / REST API 기반으로 이루어짐- 컨테이너/서비스는 포트 바인딩 방식으로 외부에 기능을 제공- 데이터는 분산 DB 지향이 기본- 운영은 DevOps + 자동화 기반의 CI/CD와 연계되는 것을 기본 전제로 함 1) 코드 베이스- 버전 관리가 가능한 하나의 코드베이스와 이를 이용한 다양한 배포- 기본적으로는 실제 release될 수 있는..

NodePort 아키텍처 동작 흐름- 과정 : 외부 -> 노드(NodePort) -> 서버(Port) -> 파드(targetPort) -> 컨테이너(containerPort) (1) NodePort- 노드에 실제로 열리는 외부 포트- 모든 노드의 IP에 31080 같은 포트가 열림 (외부 사용자는 노드IP:31080으로 접속)(2) Port (클러스터 내부 진입점)- Service의 내부 포트로 클러스터 내부에서 보이는 서비스 포트- Service(IP, 즉 CluerIP)에 붙는 포트- 클러스터 내부에서 누군가 서비스이름:80으로 접속하면 이 포트로 들어옴(3) TargetPort- Service가 Pod로 보낼 때 찍는 포트- Pod의 몇 번 포트로 보낼지를 결정(4) Container Port- 컨..

(pdf p152)01. ConfigMap 생성SECLOUDIT: "Plarform as a service!"key value로 값을 넣어서 사용 ConfigMap을 사용하는 이유는?- 애플리케이션 코드와 설정값을 분리하기 위해서 사용- ConfigMap이 없다면 설정 변경할 때마다 YAML을 수정하여야 함- ConfigMap을 사용하면 설정만 따로 관리해서 설정 변경 시 ConfigMap만 수정하면 됨 (Pod는 그대로 두고 어떤 ConfigMap을 붙이느냐만 바꾸면 됨) 1) 생성 명령어- ConfigMap은 약자가 cm으로 활용# kubectl create configmap {CONFIG_MAP_NAME} --from-literal={KEY}={VALUE}--namespace={NAMESPACE_..

SAGA 패턴의 정의와 종류 왜 SAGA 패턴이 필요??예전 방식 (Monolithic)- 하나의 큰 프로그램 + 하나의 DB- 여러 작업을 하나의 DB 트랜잭션으로 묶어 처리- 중간에 실패하면 DB가 자동으로 rollback을 해줘서 개발자가 신경 쓸 게 거의 없음- 즉, DB가 모든 것을 책임짐 지금 방식 (Microservice)- 서비스가 여러 개로 나뉘고 서비스마다 각자 DB를 보유- 하나의 주문 과정이 여러 서비스에 걸쳐 있음 문제점 : 여러 주문 과정을 하나의 DB 트랜잭션으로 묶을 수 없고 중간에 실패해도 DB가 알아서 rollback 해주지 못함 => 누가 전체 취소(rollback)를 책임질 것인가? 문제가 생김 SAGA 패턴이란?- 여러 서비스에 걸친 작업을 각각의 작은 트랜잭션으로 ..

01. 공공 Cloud 추진 정책 (구축)정부의 특수성 : 기술의 특수성 -> 민간에서 먼저 도입 -> 성공적이라면? -> 정부로 도입해도 보안적이든 문제가 없다? -> 정부가 도입 시작 (충분한 성과를 보이고 / 미래에도 많이 쓰일것 같을 때 도입) -> 한 번 도입하면 쭉 들고 가야함(5~10년 이상) 현정부 - Cloud 와 AI 도입 (AI를 어떻게 하자 정도만 있고 아직 실제 도입은 없음) Cloud의 전환은 2022년부터 시작20년대부터 얘기가 나오기 시작함 (준비단계)21년도에 컨설팅 받고 22년에 실질적인 사업 시작 2023년행정안전부 전환 사업 예산이 말도 안되는 수준으로 줄어듦why? 기술적인 것이 확 바뀜VM 안 써도 잘 됌 / 훨씬 더 효율적 / 클루아드 전환계획이 클라우드 네이티..

MSA 애플리케이션 구축 - MSA 구조의 샘플 애플리케이션을 서비스별로 분리해서 각각 배포하는 실습을 진행할 예정 (UI / Gateway / API / SD-API를 모두 따로 배포) 1) 포털 영역 - kpaas-msa-configmap 생성 - MSA 서비스들이 공통으로 사용할 설정값을 ConfigMap으로 미리 정의 - 예) 서비스 주소 / 환경 변수 / 공통 옵션 => 여러 마이크로서비스가 공유할 설정을 중앙에서 관리 2) 소스 컨트롤 영역 - 서비스별 코드 저장소 분리 - 각 서비스마다 별도의 Git 리포지토리를 가짐 (1) msa-sample-api (2) msa-sample-sd-api (3) msa-sample-ui (4) ms..

01. 컨테이너 플랫폼 이해와 배포방식1) K-PaaS 표준 모델- 클라우드 인프라 위에서 애플리케이션을 개발하고 실행/운영/관리하기 위한 기반 플랫폼- 클라우드 네이티브 애플리케이션에 필요한 핵심 기능들을 공통 표준으로 정의하고 오픈소스로 제공해, 다양한 상용 PaaS 환경에서도 호환성과 일관성을 보장하는 것이 목적 2) 컨테이너 플랫폼이란?- 쿠버네티스 기반의 단독배포 (우리는 이것만 알면 됌) - 마스터 1개, 워커노드 3개로 구성- 클라우드 기반 서비스 및 운영에 필요한 부가 서비스를 지원와 스토리지 환경도 함께 제공- 디스크립션을 기반으로 정의되어 컨테이너 형태로 배포 3) 단독형 배포- 컨테이너 플랫폼을 단독으로 배포하여 독립된 쿠버네티스 환경을 제공하는 배포 방식- 외부 환경과 분리된 클러..

Amazon Bedrock- 2026까지 기업의 80%이상이 생성형 AI API를 사용하거나 생성형 AI 지원 앱을 배포할 것- 2024년 1% 미만에서 2028년까지 33% 기업 소프트웨어 앱에 에이전트 형 AI가 포함될 것- 2028년까지 일상적인 업무 결정의 15%가 에이전트형 AI를 통해 자율적으로 이루어질 것 Agentic AI로의 진화 강조- 생성형 AI 어시스턴트 -> 생성형 AI 에이전트 -> Agentic AI 시스템 (좀 더 능동적인 AI) Amazon Bedrock Nova 모델Amazon Nova2 Lite (경량 모델)Sonic : 음성 생성해주는 모델 Amazon Bedrock가 제공하는 도구- 검색 증강 생성 (RAG) - 프롬프트 증강을 통한 전문 지식 - 기업 ..