본문 바로가기
반응형

K8S80

Kubernetes의 Node Scheduling Kubernetes의 Node Scheduling은 클러스터에서 Pod가 실행될 적절한 Node를 선택하는 과정입니다. Kubernetes Scheduler가 이를 담당하며, 특정 Pod가 실행될 Node를 결정하기 위해 다양한 조건과 제약을 고려합니다.Node Scheduling의 주요 과정Scheduling 후보 Node 필터링 (Filtering)Scheduler는 클러스터 내에서 실행 가능한 Node를 찾기 위해 필터링 과정을 수행합니다.예를 들어, 다음 조건에 맞지 않는 Node는 제외됩니다:Node가 충분한 리소스(CPU, 메모리 등)를 가지고 있는지.Pod의 nodeSelector, nodeAffinity, 또는 taints에 맞는 Node인지.Node 상태가 Ready인지.적합한 Node .. 2024. 12. 19.
Kubernetes의 플랫 네트워크 1. 컨테이너 네트워크 모델 (Container Network Model)과거의 포트 매핑 문제도커와 같은 단일 컨테이너 실행 환경에서는 컨테이너 내부의 애플리케이션에 접근하려면 호스트의 특정 포트를 컨테이너의 포트와 매핑해야 했습니다. 예:애플리케이션 컨테이너가 내부적으로 8080 포트를 사용한다고 가정.외부에서 접근하려면 호스트 포트(예: 30000)를 컨테이너 포트(예: 8080)에 매핑해야 합니다: docker run -p 30000:8080 my-app문제점:복잡한 관리여러 컨테이너에서 동일한 포트를 사용하면 충돌이 발생할 수 있어, 포트를 수동으로 관리해야 함.수십 개 이상의 컨테이너를 다룰 경우 포트 매핑이 복잡해짐.동적 스케일링의 제약컨테이너를 동적으로 생성하고 스케일링하려면, 각각의 새로.. 2024. 12. 16.
pause container가 먼저 실행되는 이유가 뭘까나? Kubernetes에서 Pod가 실행될 때 pause 컨테이너가 가장 먼저 실행되는 이유는 Pod 내부의 리소스 공유와 네트워크 구성을 관리하기 위해서입니다.아래에서 구체적으로 설명하겠습니다.1. Pod의 리소스 공유 구조Pod는 여러 컨테이너를 포함할 수 있는 Kubernetes의 최소 배포 단위입니다. Pod 내부 컨테이너들은 다음과 같은 리소스를 공유합니다:네트워크 네임스페이스: 모든 컨테이너가 같은 IP와 포트를 공유.스토리지 볼륨: Pod 내 컨테이너들이 같은 디스크 볼륨을 공유.이러한 공유 환경을 설정하고 유지하려면, Pod 내부의 네임스페이스와 네트워크 공간을 관리할 주체가 필요합니다. 이를 위해 Kubernetes는 pause 컨테이너를 사용합니다.2. pause 컨테이너의 역할2.1 네임.. 2024. 12. 16.
[k8s] liveness probe, readiness probe, startup probe Kubernetes에서 liveness probe, readiness probe, startup probe는 컨테이너의 상태를 점검하고, 컨테이너가 트래픽을 수신할 준비가 되었는지, 또는 오류가 발생한 경우 다시 시작할지 결정하는 데 중요한 역할을 합니다.Liveness Probe목적: 컨테이너가 여전히 정상적으로 실행되고 있는지 확인합니다. 만약 이 검사가 실패하면 Kubernetes는 해당 컨테이너를 재시작합니다.사용 사례: 컨테이너가 실행 중이지만 응답하지 않거나 고장 나서 복구가 불가능한 상태에 있을 때 이를 감지하여 자동으로 재시작할 수 있습니다.예시: 컨테이너가 무한 루프에 빠지거나 응답하지 않을 때, liveness probe가 실패하고 Kubernetes가 컨테이너를 재시작합니다.Readi.. 2024. 12. 15.
[kubernetes] ingress controller - nginx 업그레이드 Kubernetes에서 NGINX Ingress Controller를 버전 업하는 방법은 주로 Helm을 사용하는 방법과, kubectl을 통해 직접 리소스를 업데이트하는 방법이 있습니다. 여기서는 두 가지 방법을 모두 설명드리겠습니다.1. Helm을 사용하여 NGINX Ingress Controller 버전 업그레이드NGINX Ingress Controller를 Helm을 통해 설치한 경우, Helm을 사용하여 버전을 업그레이드할 수 있습니다.1.1. NGINX Ingress Controller 버전 확인먼저, 현재 설치된 Ingress Controller의 버전을 확인합니다.bash코드 복사helm list -n 는 Ingress Controller가 설치된 네임스페이스입니다(예: ingress-ng.. 2024. 12. 9.
[kubernetes] 에러 Incompatible platform detected If this is a gpu node, did you configure the nvidia container toolkit Kubernetes에서 Incompatible platform detected If this is a gpu node, did you configure the nvidia container toolkit라는 에러가 발생하는 주된 원인은 GPU 노드에서 NVIDIA GPU를 사용하는 컨테이너가 실행될 때 NVIDIA 드라이버나 도구가 제대로 설정되지 않았기 때문입니다.이 에러는 Kubernetes 클러스터에서 GPU를 사용하려는 Pod를 배포할 때, NVIDIA GPU를 위한 필수 도구인 NVIDIA Container Toolkit이나 NVIDIA 드라이버가 올바르게 설정되지 않으면 발생할 수 있습니다.원인이 에러는 보통 다음과 같은 이유로 발생합니다:NVIDIA 드라이버 미설치 또는 잘못된 설치:GPU .. 2024. 12. 9.
[kubernetes] Backoff pulling image에러 원인과 해결책 Kubernetes에서 Back-off pulling image 에러는 일반적으로 이미지 레지스트리에서 Docker 이미지를 가져오는 데 문제가 발생했을 때 나타납니다. 이 에러 메시지에서 중요한 부분은 Back-off pulling image 뒤에 있는 이미지 이름과 태그입니다. 예를 들어, A.azurecr.io/a/image:latest와 같은 형식이 보이는데, 이 에러는 Kubernetes가 지정된 이미지를 레지스트리에서 가져오는 데 실패했음을 의미합니다.원인이 에러의 주요 원인은 다음과 같습니다:이미지 이름 오류:이미지 이름 또는 태그가 잘못되어 해당 이미지를 찾을 수 없을 수 있습니다. 예를 들어, 레지스트리 URL, 이미지 이름, 태그가 정확하지 않으면 Kubernetes는 이미지를 찾을 수.. 2024. 12. 9.
[kubernetes] 에러 Unable to connect to the server: tls: failed to verify certificate: Unable to connect to the server: tls: failed to verify certificate: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "kubernetes")설치후 kubectl 을 사용할경우 위와 같이 에러가 발생한다.인증서가 제대로 설정이 안된 문제mkdir-p $HOME/.kubesudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/configsudo chown $(id -u):$(id -g) $HOME.. 2024. 12. 8.
[Kubernetes] PDB 란? Kubernetes의 Pod Disruption Budget(PDB)는 클러스터 관리자가 의도적으로 클러스터를 변경하거나 장애가 발생했을 때, 애플리케이션의 가용성을 보호하기 위해 설정하는 제어 정책입니다. PDB는 특정 시점에 삭제되거나 중단될 수 있는 Pod의 최대 수를 제한하여 애플리케이션이 서비스 중단 없이 지속적으로 운영될 수 있도록 보장합니다.PDB의 목적가용성 유지:유지 관리 작업(노드 업그레이드, 스케일 다운 등) 또는 장애 상황에서도 애플리케이션의 최소 가용성을 보장합니다.예: 전체 Pod이 동시에 종료되지 않도록 방지.안정성 확보:Pod의 강제 중단으로 인해 서비스에 영향을 미치지 않도록 보호합니다.특히 StatefulSet과 같은 애플리케이션에서 유용합니다.PDB의 주요 구성 요소PD.. 2024. 12. 2.
helm plugin 수동 설치 - windows helm plugin install https://github.com/chartmuseum/helm-pushError: exec: "sh": executable file not found in %PATH% Helm 플러그인을 수동으로 설치helm-push 플러그인을 수동으로 설치하여 sh 없이도 사용할 수 있습니다.Git 리포지토리 복제:bash코드 복사git clone https://github.com/chartmuseum/helm-push.git바이너리 다운로드: Releases 페이지에서 Windows용 바이너리를 다운로드합니다.플러그인 디렉터리로 복사: Helm의 플러그인 디렉터리에 바이너리를 복사합니다. 디렉터리는 일반적으로 다음 경로에 있습니다:예를 들어, chartmuseum 폴더를 생성한 .. 2024. 11. 25.
daemonset, deployment, statefulset 비교 정리 Kubernetes에서 DaemonSet, Deployment, StatefulSet은 애플리케이션을 배포하고 관리하는 데 사용되는 세 가지 주요 리소스입니다. 각각의 목적과 동작 방식이 다르며, 특정 상황에 적합한 기능을 제공합니다. 이 세 가지 리소스를 자세히 설명하겠습니다. 1. DaemonSet개념: DaemonSet은 클러스터 내의 모든 노드에서 특정 애플리케이션의 복사본을 실행하도록 보장합니다. 새로운 노드가 클러스터에 추가되면, 해당 노드에도 자동으로 Pod가 생성됩니다. 마찬가지로 노드가 클러스터에서 제거되면 그 노드에서 실행 중인 Pod도 제거됩니다.주요 특징:클러스터의 모든 노드 또는 특정 레이블이 있는 노드에 애플리케이션을 배포합니다.로그 수집 에이전트, 모니터링 에이전트, 네트워크 .. 2024. 11. 10.
Istio 의 컴포넌트 1. PilotPilot은 Istio의 트래픽 관리 컴포넌트로, 서비스 간의 트래픽을 어떻게 라우팅할지 결정합니다.애플리케이션과 관련된 트래픽 규칙(예: 라우팅 정책, 리트라이, 타임아웃 등)을 관리하며, 이 정보를 각 사이드카 프록시(Envoy)에게 전달합니다.이를 통해 사용자는 트래픽 라우팅 전략을 중앙에서 제어하고, Canary 배포나 A/B 테스트 같은 트래픽 제어 정책을 쉽게 적용할 수 있습니다.2. Envoy (사이드카 프록시)Envoy는 사이드카 형태로 각 애플리케이션 Pod에 배포되는 프록시입니다. Istio는 이 Envoy 프록시를 활용해 트래픽을 가로채고 제어합니다.Envoy 프록시는 서비스 간의 모든 트래픽을 가로채서 관찰하고, Pilot에서 전달받은 트래픽 관리 정책을 기반으로 트래.. 2024. 11. 9.
반응형

티스토리툴바