본문 바로가기

k8s

(22)
[k8s] Kubernetes 명령어 비교: kubectl apply vs kubectl create Kubernetes에서 자원을 관리하고 배포하는 데는 다양한 명령어가 사용됩니다. 이 글에서는 Kubernetes의 핵심 명령어인 kubectl apply와 kubectl create의 차이점을 살펴보고, 언제 어느 명령어를 사용해야 하는지를 알아보겠습니다. kubectl apply의 특징 및 사용법 kubectl apply 명령어는 Kubernetes 리소스의 구성을 선언적으로 관리하는 데 사용됩니다. 이 명령어는 리소스의 현재 상태를 JSON 또는 YAML 파일 형식으로 지정된 원하는 상태와 비교하여, 필요한 변경사항을 적용합니다. 주요 특징 변경사항만 적용: 기존 리소스의 설정을 수정하거나 추가할 때 유용합니다. 선언적 업데이트: 리소스의 전체 정의를 제공하고 Kubernetes가 필요한 변경을 파..
[k8s][Error] Arm-AMD CPU 사이 문제 해결 - 파드 생성 시 CrashLoopBackOff, exec user process caused: exec format error 문제 에러 상황 Docker를 이용해서 개발한 서비스를 컨테이너로 빌드하였고, 레포지토리에도 push하였습니다. 이 이미지를 이용해서 쿠버네티스로 Deployment를 배포하였고 계속해서 CrashLoopBackOff -> Error -> CrashLoopBackOff 가 반복되는 상황 파드의 로그를 확인해보면 다음과 같습니다. standard_init_linux.go:228: exec user process caused: exec format error exec format error? 보통은 Dockerfile의 ENTRYPOINT, CMD 가 잘못 선언되었거나, 실행할 스크립트의 권한이 없는 등 도커 이미지를 컨테이너로 실행할 때 잘못 설정해서 생기는 문제라고 합니다. 하지만 local에서 해당 이미지를..
[k8s][따배쿠] 쿠버네티스 아키텍처 - namespace https://www.youtube.com/watch?v=pfkx8KDAZyk&list=PLApuRlvrZKohaBHvXAOhUD-RxD0uQ3z0c&index=8 본 포스팅은 따배쿠(따라하면서 배우는 쿠버네티스) 4-2. 쿠버네티스 아키텍처 - namespace 편을 보고 정리한 내용입니다. 쿠버네티스 namespace 쿠버네티스에서 namespace란 - 클러스터 하나를 여러 개의 논리 적인 단위로 사용할 수 있게 해주는 k8s API - 쿠버네티스 클러스터 하나를 여러 팀이나 사용자가 공유하게 됩니다. - 용도에 따라 실행해야 하는 앱을 구분할 때 사용할 수 있습니다. 위의 그림 처럼 클러스터가 하나여도 그 안에서 논리적으로 구분하고자 할 때 namspace를 사용합니다. 위의 예시에서는 실행할 애..
[k8s][따배쿠] 쿠버네티스 아키텍처 - Kubernetes 동작 원리 https://www.youtube.com/watch?v=Iue9TC13vPQ&list=PLApuRlvrZKohaBHvXAOhUD-RxD0uQ3z0c&index=7 본 포스팅은 따배쿠(따라하면서 배우는 쿠버네티스) 4-1. 쿠버네티스 아키텍처 - Kubernetes 동작 원리 편을 보고 정리한 내용입니다. 쿠버네티스에서 컨테이너 동작 Flow 쿠버네티스에서 서비스를 운영하기 위한 전체 동작 Flow는 다음과 같습니다. 하나하나씩 살펴보도록 하겠습니다. 1. Docker push hub.example.com/nginx 개발자 혹은 운영자는 컨테이너를 쿠버네티스 플랫폼에 올려 사용하는 것이 목적입니다. 이 경우 우선 Docker를 이용하여 컨테이너를 빌드(생성)합니다. 컨테이너는 main UI를 만드는 컨테..
[k8s] 파드를 수평으로 Scale Out 하기(HorizontalPodAutoscaler, HPA) HorizontalPodAutoscaler(HPA) 쿠버네티스에서는 CPU 사용량 이나 기타 메트릭을 체크하여 파드의 개수를 스케일하는 기능을 가지고 있습니다. Horizontal Pod Autoscaler로 지정한 메트릭을 컨트롤러가 체크하여 부하에 따라 필요한 파드의 레플리카수가 되도록 자동으로 파드를 늘리거나 줄입니다. Horizontal Pod Autoscaler는 쿠버네티스 API 리소스 및 컨트롤러로 구현됩니다. 리소스는 컨트롤러의 동작을 결정한다. 컨트롤러는 평균 CPU 사용률, 평균 메모리 사용률 또는 다른 커스텀 메트릭과 같은 관찰 대상 메트릭이 사용자가 지정한 목표값과 일치하도록 레플리케이션 컨트롤러 또는 디플로이먼트에서 레플리카 개수를 주기적으로 조정합니다. HPA(Horizontal..
[k8s] 인그레스(Ingress) 인그레스(Ingress) 인그레스(Ingress)는 주로 클러스터 외부에서 안에 있는 파드에 접근할 때 사용하는 방법입니다. 서비스와의 차이점은 주로 L7 영역의 통신을 담당해서 처리한다는 것입니다. 인그레스는 클러스터 외부에서 안으로 접근하는 요청들을 어떻게 처리할지 정의해둔 규칙에 대한 모음입니다. 클러스터 외부에서 접근해야 할 URL을 사용할 수 있도록 하고, 트래픽 로드밸런싱, SSL 인증서 처리, 도메인 기반 가상 호스팅도 제공합니다. 인그레스 자체는 이런 규칙들을 정의해둔 자원이고, 실제로 동작시키는 것은 인그레스 컨트롤러(Ingress Controller)입니다. 클라우드 서비스(AWS EKS 등..)를 사용하면 별다른 설정없이 자체 로드밸런서 서비스와 연동해서 인그레스를 사용할 수 있습니다..
[k8s] StatefulSet(스테이트풀셋) Stateless Application vs Stateful Application Stateless Application 클라이언트와 서버 관계에서, 서버가 클라이언트의 상태를 보존하지 않는 형태의 서비스입니다. 말 그대로 상태가 없는 애플리케이션으로 대표적으로 Apache, Nginx와 같은 Web server가 있습니다. Stateless 애플리케이션은 쿠버네티스에서 삭제/생성 시 같은 역할을 하는 애플리케이션을 생성하면됩니다. 이 때 앱의 이름은 중요하지 않습니다. Stateless 애플리케이션은 Volume이 반드시 필요하진 않지만 하나의 볼륨에 모든 애플리케이션이 연결되어 사용할 수 있습니다. 쿠버네티스에서는 Replication Controller, Replicaset, Deployment와 ..
[k8s] RBAC(Role Based Access Control)란 리소스 표현과 동작 쿠버네티스는 리소스 조작을 API Server에 집약시키고 있습니다. 그리고 API Server는 REST 형식으로 리퀘스트를 받습니다. URL로 리소스를 표현하고 거기에 대해 HTTP 메소드로 조작을 합니다. 쿠버네티스의 RBAC에서는 조작을 Verb라고 부릅니다. 참조, 작성, 갱신, 부분 갱신, 삭제 조작에 각각 Verb가 있어서 HTTP 메서드와 대응하고 있습니다. HTTP Method Verb Verb(컬렉션) GET, HEAD get(watch) list(watch) POST create - PUT update - PATCH patch - DELETE delete deletecollection 파드, 서비스, 시크릿과 같은 리소스에 대해 각 계정이 갖고 있는 '역할'이 이런..
[k8s] 쿠버네티스의 인증과 인가 쿠버네티스의 인증과 인가는 API Server 상에서 일어나는데, 인증, 인가, Admission Control 이라는 3단계가 있습니다. 인증 인증은 해당 계정이 누구인지, 어떤 그룹에 속하는지를 확인하는 것입니다. 쿠버네티스가 지원하고 있는 대표적인 방식, 플로그인은 다음과 같습니다. X509 클라이언트 인증서 정적 토큰 파일 부트스트랩 토큰 정적 비밀번호 파일 Service Account 토큰 OpenID Connect 토큰 인가 인가는 인증이 끝난 계정에 대해 조작할 수 있는 리소스와 가능한 조작을 한정하는 것입니다. 인가 방식에는 여러 가지가 있지만 그중에서도 RBAC(Role Based Access Control)가 사실상 표준으로 자리매김하고 있습니다. Admission Control Ad..
[k8s] 쿠버네티스의 계정 - User Account, Service Account 사용자 계정(User Account) 쿠버네티스는 '사람'을 관리하는 장치를 가지고 있지 않습니다. 정확히 말하자면 일반 사용자를 나타내는 오브젝트가 없습니다. 쿠버네티스는 일반 사용자의 관리를 외부에게 맡기고 있습니다. 여기서 외부란 Azure AD나 Google 계정과 같은 ID 관리 시스템입니다. 일반 사용자는 외부에서의 인증을 거친 후에 쿠버네티스의 리소스를 조작합니다. 여러 클러스터를 조합하여 사용하는 것이 당연시되므로 모든 시스템이나 서비스에서 개별적으로 사용자 ID를 관리하는 것이 어려움을 더 증가시키는 것이 쿠버네티스 자체에서 ID를 관리하지 않는 이유입니다. 여러 클러스터를 사용하던 사용자가 회사를 관둔다면 해당 ID를 돌아다니며 삭제하는 절차를 만들어야할 것입니다. 서비스 계정(Serv..