지식의 추월차선

Pod가 쿠버네티스 API와 상호작용할 때 사용하는 계정이 바로 Service Account 이다. 무조건 사용하는 것! 여러분들이 설정한 적 없어도 이미 설정되어있는 것이 그것이 바로 service account목적 클러스터에 있는 모든 Pod는 쿠버네티스 API 서버와 상호작용할 수 있는 권한이 필요하는데 이때 사용하는 계정이 바로 Service Account이다. 이는 User Account와는 다르다. Service Account는 pod와 같은 애플리케이션이 클러스터 내에서 수행할 작업을 위해서 사용하는 것이다.쿠버네티스는 기본적으로 각 네임스페이스의 default 라는 Service Account가 자동으로 생성된다. 그래서 별도의 Service Account를 생성하지 않거나 지정하지 않는다..

kubectl create와 kubectl apply는 Kubernetes 클러스터에서 리소스를 생성하고 업데이트하는 데 사용되는 명령어입니다.이 두 명령어의 차이점은 리소스를 생성하는 것, 리소스를 생성하거나 업데이트 하는 것입니다.kubectl create주요 목적: 새 리소스를 생성합니다.동작: 지정된 매니페스트 파일을 읽고, 해당 리소스가 클러스터에 존재하지 않는 경우 새로 생성합니다. 이미 존재하는 경우 오류를 발생시킵니다.사용 예시:kubectl create -f kubectl apply주요 목적: 리소스를 생성하거나 업데이트합니다.동작: 지정된 매니페스트 파일을 읽고, 해당 리소스가 클러스터에 존재하지 않는 경우 새로 생성합니다. 이미 존재하는 경우 매니페스트 파일의 내용에 따라 리소스를 업..

kubectl port-forward 명령어는 Kubernetes 클러스터 내의 Pod에 있는 하나 이상의 포트를 로컬 컴퓨터의 포트에 전달(포워딩)하는 데 사용됩니다. 이 명령어를 사용하면 개발자나 관리자는 클러스터 내부 네트워크에 직접 연결되어 있지 않아도 로컬 시스템에서 클러스터 내의 서비스에 접근할 수 있습니다. 이 기능은 디버깅과 개발 작업에 매우 유용합니다. 사용법 kubectl port-forward [LOCAL_PORT:]REMOTE_PORT kubectl port-forward는 테스트 및 디버깅 용도로 주로 사용되며, 생산 환경에서는 신중하게 사용해야합니다. 포트포워딩을 사용하면 로컬머신과 pod 사이에 직접적인 네트워크 연결이 생성되기 때문에 보안상의 위험을 증가할 수 있습니다. 당연..

쿠버네티스의 구조를 이해하기 전에 반드시 이해하고 있으면 좋을 만한 것은 노드, 클러스터에 대한 용어입니다. 노드는 쿠버네티스에서 가장 기본적인 작업 단위이며 단일 서버(물리적 또는 가상)를 나타내며, 쿠버네티스 클러스터의 일부입니다. 각 노드는 컨테이너화된 애플리케이션을 실행할 수 있는 자원(CPU, 메모리, 저장소 등)을 제공합니다. 그렇다면 이렇게 실질적으로 일을 하는 노드를 관리 및 제어 역할하는 무엇인가도 필요하겠죠? 그것도 바로 노드가 합니다. 쿠버네티스는 그 노드를 마스터 노드라고 합니다. 마스터 노드는 쿠버네티스 클러스터를 관리하고 제어하는 중앙 제어 노드입니다. 당연히 이 마스터 노드 안에는 주요한 구성요소 들이 있지만 이번 포스팅에서는 용어에 대한 개념만 이야기하도록 하겠습니다. 쿠버네..

쿠버네티스(Kubernetes)가 처음에 도커(Docker)를 주요 컨테이너 런타임으로 사용하면서 시작했지만, 나중에 CRI(Container Runtime Interface)를 도입한 이유는 여러가지가 있으며 결론적으로는 쿠버네티스의 사용성이 점차 넓어지면서 쿠버네티스의 유연성, 확장성 및 범용성을 향상시키기 위한 전략적인 선택이었다고 합니다. 쿠버네티스는 다양한 환경과 사용 사례를 지원하는 범용 오케스트레이션 시스템을 목표로 했습니다. 처음에는 도커가 유일한 런타임 옵션이었지만, 시간이 지남에 따라 다른 컨테이너 런타임 기술들도 발전했습니다. CRI를 도입함으로써 쿠버네티스는 도커 외에도 containerd, CRI-O와 같은 다양한 컨테이너 런타임을 지원할 수 있게 되었습니다. CRI는 쿠버네티스와..

kubectl auth can-i 명령어는 쿠버네티스(Kubernetes)에서 현재 사용자 또는 서비스 어카운트가 특정 작업을 수행할 수 있는지 여부를 확인하는 데 사용됩니다. 이 명령어는 Role-Based Access Control (RBAC) 정책에 따라 사용자에게 부여된 권한을 검증하는 데 유용합니다. kubectl auth can-i get pods --namespace dev --as username 위의 명령어는 dev 네임스페이스에서 username 사용자가 pods를 조회할 수 있는지 확인합니다. RBAC 문제 나왔을 때 잘 했는지 체크하고 싶으면 auth can-i 명령어로 확인해보시면 되겠습니다.

여러분 CKA 범위를 보면 트러블슈팅이 30% 비율로 출제된다고 되어있어요. 즉, 무조건 나온다고 봐야겠죠? 어떤 문제가 나올지는 모르겠지만 정리할 수 있는 부분들은 정리해두려요! 그리고 나서 나중에 시험에 적용해야겠어요 1. Toubleshoot application fauilure 2 tier 구조로 문제가 나온다면 클라이언트 -> 웹서비스 -> 웹 -> DB 서비스 -> DB 순으로 확인해보기 서비스에 있는 Selector와 Pod에 있는 Selector가 일치하는지 체크하기 kubectl describe service 파드를 확인하기 kubectl get pods 에서 restart 횟수도 체크하기 kubectl describe pod 로 어떤 이슈인지 체크하기 kubectl logs 로그로 뭔가..

Deployment는 ReplicaSet을 관리하고, 파드의 롤아웃(업데이트) 및 롤백을 처리하는 더 고급 수준의 리소스인데요. 무중단 업데이트, 버전 관리, 롤백 등의 기능을 제공합니다. 그래서 오늘은 Deployment의 롤링업데이트에 대해서 이해해봅시다. maxUnavailable maxUnavailable: 업데이트 과정 중 사용할 수 없게 되는 최대 파드 수를 정의합니다. 25%의 maxUnavailable은 원하는 파드 수(3개)의 25%를 의미합니다. 즉, 3 x 0.25 = 0.75, 내림하여 0개입니다. 그러나 maxUnavailable은 최소 1개 파드를 의미해야 하므로, 실제적으로 사용할 수 없는 최대 파드 수는 1개가 됩니다. 해당 내용은 쿠버네티스 공식 문서에 기재되어있습니다. m..

Role Role은 특정한 네임스페이스에 국한되어 사용됩니다. 즉, Role로 정의된 권한은 해당 Role이 생성된 네임스페이스 내에서만 유효합니다. 사용 사례: 특정 네임스페이스에서 파드를 생성하거나 조회하는 등의 작업을 허용하고 싶을 때 사용합니다. ClusterRole ClusterRole은 클러스터 전체에 걸쳐 적용됩니다. 이는 네임스페이스를 초월하여 클러스터 수준의 리소스(예: 노드)에 대한 접근 권한을 제어하거나, 모든 네임스페이스에서 특정 작업을 수행할 수 있는 권한을 부여하는 데 사용됩니다. 사례: 클러스터 전체의 모든 파드를 조회하거나, 특정 클러스터 수준의 리소스(예: 노드, 지속적 볼륨)에 대한 접근을 제어할 때 사용합니다.

Role은 특정 네임스페이스 내에서 사용자 또는 그룹에게 허용되는 권한을 정의합니다. Role은 해당 네임스페이스 내의 리소스에 대한 접근 권한을 제어합니다.Role을 사용하여 특정 리소스(예: 파드, 서비스 등)에 대한 CRUD(Create, Read, Update, Delete) 작업을 수행할 수 있는 권한을 정의합니다. 예시를 들어서 바로 이해해봅시다. apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: mynamespace name: pod-reader rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "watch", "list"] RoleBinding은 특정 R..