kubernetes

kube 커맨드를 실행하기 위해 Kube API Server에 명령어를 Query해주어야한다.API Server에 Query하기 위해서는 User 인증을 위해 매번 User Certificate를 함께 보내주어야한다. kubectl get pods --server kubernetes.docker.internal:6443 \ --client-key admin.key \ --client-certificate admin.crt \ --certificate-authority ca.crt 매번 이렇게 커맨드를 실행할 수는 없지 않은가? 이 과정을 간소화시키기 위해 Context와 KubeConfig 파일이 존재한다. KubeConfig클러스터에 접근하고 상호작용하기 위해 필요한 설정을 포함하는 파일kubectl을..

Cluster내에서는 여러 Worker Node들이 연결되어 있고,  각 Node에는 여러 Pod들이 배치될 수 있다.배치된 Pod들은 CPU를 많이 잡아먹는 Workload, 혹은 메모리를 많이 잡아먹는 Workload 등 다양한 요구사항을 가질 수 있다. 그리고 Worker Node 또한 각각 사양이 다를 수 있기에, 이러한 요구사항과 cluster 내의 Node 상황에 맞춰 Pod를 효율적으로 Scheduling 하는 것이 중요하다. 효율적인 Pod의 Scheduling을 위해 Kubernetes에서는 Resource Requests와 Limits를 사용한다.이번에는 이 두 요소를 알아보도록 한다. Resource RequestsContainer가 생성될 때, 특정 용량을 요청하는 것, 해당 pod..

Taint & Tolerant어떤 pod가 특정 node에 schedule되는 것을 제한하는 것 (set restriction)즉, 특정 node가 특정 pod만 수용할 수 있도록 하거나 특정 node에 특정 pod가 배치되지 않도록 하는 수단이다. Taint는 node에 지정하는 요소이고, Tolerant는 pod에 지정하는 요소다.이해하기 쉽게 보자면, Taint는 '벌레 퇴치 스프레이', 그리고 Tolerant는 Taint에 적응할 수 있는 면역력으로 생각할 수 있다.  Taint와 Tolerant를 이해하기 위해 아래와 같이 Node와 Pod들이 있다고 가정해본다.  Node라는 사람 객체에 Pod라는 벌레 객체가 붙는다. 이때 Node에 예를 들어 app=prd 라는 Taint를 적용하게되면, ..

Pod를 새롭게 생성하면 Master Node(Control plane)의 Scheduler가 pod를 실행시킬 node를 선택하고 배치한다.그럼 이 Scheduler는 어떤 기준으로 pod를 실행시킬 node를 결정하는 것일까?cluster내의 node들은 모두 같은 사양을 가질수도 있지만, 각기 다른 스펙의 사양을 가질 수도 있다. 워크로드 또한 리소스 자원을 많이 요구하는 것이 있고, 비교적 적은 양을 요구하는 것이 있다. 각 node들의 리소스를 효율적으로 사용하기 위해서는 다양한 제약 조건과 요구사항 등을 고려하여 pod를 배치해야한다. 특정 워크로드가 적합한 노드에서 실행되도록 할 수 있다.이번 글에서는 Label과 Selector, 추가로 Annotation에 대해 알아보도록 한다. Labe..

이번에는 Public Cloud의 Kubernetes 서비스와 로드밸런서 서비스의 연동을 진행해본다.Naver Cloud Platform(이하 NCP)의 Kubernetes 서비스, NKS를 이용해볼 것이며 로드밸런서에 SSL 인증서까지 연결하는 과정까지 진행해보도록 한다. 사용된 예제 ALB Ingress Controller 활용 예제 guide.ncloud-docs.com NKS 클러스터 생성NKS에 클러스터를 생성하고, 이 클러스터에 접속해서 작업하기 위해 몇가지 선행작업이 필요하다. 1. ncp-iam-authenticator 설치 및 설정NKS의 API를 호출하기 위해 IAM 인증이 필요하다. 이를 위해 ncp-iam-authenticator를 다운받아야한다. ncp-iam-authenticat..

앞서 알아보았던 Service 중 외부 요청을 처리하기 위한 것에는 NodePort가 있었다. NodePort는 클러스터 내의 모든 노드에 특정 포트를 오픈시켜 외부로부터 접근할 수 있도록 하는 서비스이다. 이러한 방식으로 클러스터 내부 네트워크로 접근하는 방식에는 사실 몇가지 애로사항이 존재한다. 포트 사용 문제 NodePort는 각 서비스별로 하나의 포트를 고정으로 사용한다. NodePort 기본 정의에 따라 30000~32767 사이의 포트만 지정해줄 수 있다. SSL 인증서 사용 불가 이러한 애로사항을 해결해주기 위해 LoadBalancer 서비스를 사용할 수 있다. 하지만 LoadBalancer는 Public Cloud에 많이 의존하게 되는 것부터 노출시킬 서비스에 대해 각각 IP주소를 가진다는..

Helm kubernetes의 패키지 매니저, 배포하는 환경에 따라 설정값을 따로 정의해서 배포할 수 있도록 패키지 매니저 역할을 한다. Helm에서 패키지는 ‘Chart’라고 하며, chart는 kubernetes 애플리케이션의 리소스 정의로 이루어진다. Helm을 통해 Chart를 설치하는 과정은 Chart가 정의된 helm repo를 추가하고, 해당 repo를 통해 install한다. Helm 아키텍쳐 Helm 아키텍쳐의 구성요소에는 쿠버네티스 클러스터, Helm 클라이언트, Helm Chart Repository가 있다. Helm 클라이언트가 Chart Repository로부터 Chart를 다운로드받고, 이 Chart를 기반으로 쿠버네티스 클러스터의 API 서버와 통신해 Chart를 적용하게 된다..

컨테이너 설정파일을 관리하는 방법으로는 컨테이너 이미지를 빌드할때에 복사하거나, 컨테이너를 실행했을 때에 외부 호스트에서 파일을 연결해주는 방법이 있다. 쿠버네티스에서는 ConfigMap 리소스를 통해 설정파일을 관리하는 방법을 제공한다. ConfigMap 컨테이너의 환경설정 값을 저장하기 위한 리소스로 키-값 쌍의 데이터를 저장한다. ConfigMap에는 주로 Application의 설정값, 컨테이너의 환경변수, 설정파일과 같은 데이터를 저장한다. 아래는 ConfigMap을 정의하는 Manifest이다. apiVersion: v1 kind: ConfigMap metadata: name: nginx-config data: NGINX_PORT: "8080" NGINX_SERVER_NAME: "my-ngin..