kubernetes

kOps클라우드 환경에 kubernetes 클러스터를 배포할 수 있게 도와주는 클러스터 배포 자동화 오픈소스 툴 보통 각 CSP 별로 Managed Kubernetes 서비스가 존재한다. (AWS의 EKS, GCP의 GKE, Azure의 AKS 등등) 이러한 Managed 서비스와는 비용계산이나 배포 방식 등이 다르다.예를 들어, EKS는 Control plane을 AWS managed 방식으로 사용하기에 그 비용이 많이 나온다.또한 Control Plane은 AWS managed라 직접 접근할 수 없다.kOps는 이러한 master node를 사용자가 직접 관리하게 함, 따라서 Control Plane 노드에 대한 접근도 가능하다인스턴스 유형도 조절이 가능해, 싸게 간단한 클러스터를 구축할 수 있다.k..

ABACAttribute-Based Access Control, User나 Group에 Permission Attribute를 지정해 접근을 제어하는 방식이 방법은 개별 User나 Group에 대해 각각 권한 설정을 해줌에 따라 복잡하고 세밀한 권한제어가 가능하다. 허나 User나 Group의 수가 증가하게되는 경우, 이들을 일일히 ABAC로 권한 설정을 해주기는 어려울 것이다.   ABAC policy 파일의 구성은 다음과 같다. 아래 Policy는 user 'jane'이 default namespace의 pod를 읽을 수 있도록 하는 내용이다. # abac_policy.json{ "apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": ..

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주소를 가진다는..