14ben's Home

Manual Pod Scheduling노드에 수동으로 Pod를 스케줄링하는 다양한 방법을 살펴볼 예정클러스터에 스케줄러가 없을 때 어떻게 해야 할지에 대해 논의내장된 스케줄러를 사용하지 않고, 직접 Pod를 스케줄링하는 방법에 대해 설명할 것임.  스케줄러의 백엔드 작동 방식간단한 Pod 정의 파일을 시작점으로 설명모든 Pod는 기본적으로 설정되지 않은 Node Name이라는 필드를 가지고 있음.Pod 매니페스트 파일을 만들 때 이 필드를 명시하지 않음.Kubernetes는 이 필드를 자동으로 추가함.스케줄러는 모든 Pod를 검사하여 이 속성이 설정되지 않은 Pod를 찾음.이러한 Pod들은 스케줄링 후보가 됨.스케줄링 알고리즘을 실행하여 적합한 노드를 식별.노드가 식별되면, 노드 이름 속성을 노드의 이름..

인증 시험 팁 - Kubectl을 사용한 명령형 명령어주로 정의 파일을 사용하는 선언형 방식을 사용할 것이지만,명령형 명령어는 일회성 작업을 빠르게 수행하고 정의 템플릿을 쉽게 생성하는 데 유용할 수 있음.시험 동안 시간을 절약하는 데 큰 도움이 될 수 있음. 유용한 옵션들--dry-run: 명령어를 테스트하려면 --dry-run=client 옵션을 사용.리소스가 실제로 생성되지 않고, 명령어가 올바른지와 리소스를 생성할 수 있는지를 알려줌.-o yaml: 리소스 정의를 YAML 형식으로 화면에 출력이 두 가지 옵션을 조합하여 리소스 정의 파일을 빠르게 생성한 후, 필요에 따라 수정하고 리소스를 생성할 수 있음. POD 생성1. NGINX Pod 생성kubectl run nginx --image=ngin..

1. Kubernetes의 명령형 및 선언형 접근 방식Kubernetes에서 명령형(imperative)과 선언형(declarative) 접근 방식에 대해 학습 2. 명령형 및 선언형 접근 방식 이해2.1 비유를 통한 이해친구의 집을 방문하기 위한 두 가지 접근 방식명령형 접근: 택시 기사에게 길을 지시하는 방식.선언형 접근: 목적지만 지정하고 시스템이 길을 찾도록 하는 방식. 2.2 인프라 관리에서의 접근 방식Imperative (명령형 접근)인프라 프로비저닝을 단계별로 지시하는 방식.예: VM을 프로비저닝하고, NGINX를 설치하고, 설정 파일을 편집하고, 소스 코드를 다운로드한 후 NGINX를 시작하는 과정.Declarative (선언형 접근)요구 사항을 선언하고 시스템이 이를 충족하도록 하는 방식..

Kubernetes 네임스페이스 네임스페이스의 개념네임스페이스를 이해하기 위해 다음과 같은 비유를 사용두 명의 마크라는 이름을 가진 소년이 있음.구분을 위해 각자의 성(스미스, 윌리엄스)으로 부름.각 소년은 다른 집에 속해 있음.각 집 안에서는 단순히 이름으로만 소통집 밖에서는 전체 이름을 사용해 소통각 집은 자신만의 규칙과 자원을 가짐   Kubernetes의 네임스페이스이러한 집들은 Kubernetes의 네임스페이스와 같음.지금까지 우리는 기본 네임스페이스에서 작업해 왔음.기본 네임스페이스는 클러스터가 처음 설정될 때 자동으로 생성됨.Kubernetes는 내부 목적을 위한 네임스페이스를 따로 생성함kube-system: 네트워킹 솔루션, DNS 서비스 등을 위한 네임스페이스kube-public: 모든..

Kubernetes Services - Load Balancer   NodePort Service 복습NodePort 서비스는 외부 사용자가 클러스터의 워커 노드의 포트에서 애플리케이션에 접근할 수 있게 도와줌.예를 들어, Voting 앱과 Result 앱이 프론트엔드 애플리케이션이 있다클러스터에 4개의 노드가 있고,외부 사용자가 애플리케이션에 접근할 수 있게 NodePort 서비스를 생성한다고 가정. NodePort Service의 한계NodePort 서비스는 노드의 포트에서 트래픽을 받아 해당 포트로 라우팅함.그러나, 사용자가 애플리케이션에 접근할 수 있는 URL을 무엇으로 제공해야 할까?각 노드의 IP와 노출된 서비스의 포트를 조합하여 접근할 수 있음.예: Voting 앱의 경우 IP와 포트 조합이..

Kubernetes Cluster IP Services 전체 스택 웹 애플리케이션 구성다양한 종류의 Pod들이 애플리케이션의 각 부분을 호스팅프론트엔드 웹 서버를 실행하는 여러 Pod백엔드 서버를 실행하는 여러 PodRedis와 같은 키-값 저장소를 실행하는 여러 PodMySQL과 같은 지속형 데이터베이스를 실행하는 여러 Pod웹 프론트엔드 서버는 백엔드 서버와 통신해야 하며,백엔드 서버는 데이터베이스와 Redis 서비스와도 통신해야 함. 서비스 간 연결 설정의 필요성Pod들은 IP 주소를 가지고 있으나, 이 IP 주소는 고정적이지 않음.Pod는 언제든지 다운될 수 있고, 새로운 Pod가 계속 생성됨.따라서, 애플리케이션 간의 내부 통신에서 이러한 IP 주소를 신뢰할 수 없음.특정 프론트엔드 Pod가 백..

Kubernetes Service애플리케이션의 다양한 구성 요소 간 외부 애플리케이션과의 통신을 가능하게 함. Kubernetes Service의 역할Kubernetes Service는 애플리케이션 간, 그리고 애플리케이션과 사용자 간의 연결을 도와줌.  예를 들어, 애플리케이션에는 프론트엔드, 백엔드, 외부 데이터 소스에 연결하는 다양한 섹션의 Pod 그룹이 있음.Service는 이러한 Pod 그룹 간의 연결을 가능하게 함.Service는 프론트엔드 애플리케이션을 최종 사용자에게 제공하고,백엔드와 프론트엔드 Pod 간의 통신을 도우며, 외부 데이터 소스와의 연결을 설정함.Service는 애플리케이션의 마이크로서비스 간의 느슨한 결합을 가능하게 함. Service의 사용 사례  1. 외부 통신Pod에 웹..

Kubernetes Deployment Pod, ReplicaSet 등의 Kubernetes 개념을 배제하고,프로덕션 환경에서 애플리케이션을 배포하는 방법 프로덕션 환경에서의 애플리케이션 배포웹 서버를 프로덕션 환경에 배포할 때 필요한 조건여러 인스턴스를 실행새로운 버전의 애플리케이션이 Docker Registry에 업로드될 때 무중단 업그레이드 필요모든 인스턴스를 한 번에 업그레이드하지 않고 순차적으로 업그레이드하는 롤링 업데이트 필요예상치 못한 오류 발생 시 최근 변경 사항을 롤백할 수 있어야 함여러 변경 사항을 일시 정지 후 한 번에 적용하는 기능 필요 Kubernetes Deployment의 기능Deployment는 Pod와 ReplicaSet을 관리하는 상위 개념Deployment의 주요 기능무..