지식의 추월차선

NetworkPolicy 문제도 무조건 나오는 단골 문제라고들 함 그래서 이번에 제대로 정리해서 절대로 틀리지 말아야되겠다 생각에 정리해봅니다.정의 NetworkPolicy는 네트워크 보안을 강화하기 위한 리소스, 파드간 통신을 제어하고 제한하는 역할을 합니다. 일반적으로 클러스터에 있는 모든 파드들은 서로 어떠한 설정없이 통신이 가능하죠. 그래서 이 NetworkPolicy를 사용하면 파드간에 허용된 트래픽을 세밀하게 정의할 수 있습니다. 즉, NetworkPolicy는 허용 규칙만 지정할 수 있으며, 명시적으로 허용되지 않은 트래픽은 기본적으로 차단됩니다.NetworkPolicy는 네임스페이스 내에서 특정 파드에 대해 허용된 Ingress/ Egress를 제어합니다. NetworkPolicy는 레이블..

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

kubectl edit deployment nginx-deployment 기본적으로 실행중인 파드의 spec 부분은 절대로 삭제할 수가 없다. 따라서 만약에 진짜 실행중인 POD의 spec(specifications)을 삭제하려면 2가지 방법이 있다. 1. kubectl edit pod 명령어로 edit 하기. 그러나, edit 한다고해도 편집은 안될거고 거부당할 것이다. 그러나, /tmp 디렉토리 밑에 편집시도했던 yaml파일이 임시로 저장될 것이다. 그러면 기존에 있는 pod를 삭제하고 다시 이 임시 파일로 apply, create 등으로 다시 배포하면 된다! 2. 현재 실행중인 pod를 yaml 파일로 저장해서 배포하기 kubectl get pod nginx -o yaml > new-nginx.ya..

리전 : 데이터센터의 그룹 리전을 선택할 때는 몇가지 고려해야하는 상황이 있다. 1. 국가별로 준수해야하는 보안준수사항이 있기 때문에 보안 준수해야할 내용에 대해서 사전에 점검해야한다. ( Compliance) 2. 지연시간 고려 ( Latency) 애플리케이션을 많이 사용할 유저들이 위치해 있는 리전을 선택하는 것이 가장 바람직하다. 3. AZ ( Available Service ) 모든 리전에 가용성 영역이 있는 것이 아니니 내가 아키텍처를 그리고자하는 리전에 가용성 영역이 제공되는지 파악하자 4. 요금 리전 별로 요금이 다르기 때문에 도입 전에 내가 선택한 리전의 요금이 어떻게 되어있는지 체크해야한다. 가용성 영역( Acailability Zones ) : 모든 리전에는 AZ가 있다 일반적으로 3개..

23년도 안에 CKA 자격증을 취득하겠다 라고 결심했는데 이래저래 바쁘다는 핑계로 미루다미루다 12월까지 왔네요. 그래도 23년도가 끝나기전에 취득해서 다행이라고 생각합니다. 23년 12월 12일 20시에 시험을 치뤘으며 최대한 기억나는 유형들을 공유해보려고합니다. 준비하실 때 참고가 되시길 바라겠습니다. CKA 자격증을 추천하는가 ? 개인적인 의견으로 대답하자면 100% 네! 입니다. 쿠버네티스 공부 입문자라면 CKA 자격증을 목표로 공부하신다면 쿠버네티스에 대한 이해도를 많이 얻어 갈 수 있을 것이라고 생각하기에 저는 CKA 자격증 준비하시는 것을 너무 추천드립니다! 쿠버네티스를 처음에 익히기에 정말 많은 도움이 됩니다. 출제된 문제 유형, 배점, 난이도는? 17문제 출제 되었고 배점은 4점, 7점,..

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 로그로 뭔가..

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..

쿠버네티스(Kubernetes)에서 taint는 노드에 적용되어 해당 노드에 파드가 스케줄될 수 있는지 여부를 결정하는 메커니즘입니다. taint를 사용하면 특정 노드에 파드가 할당되는 것을 제어할 수 있으며, 이는 노드에 '오염'을 추가하는 것과 유사합니다. 파드가 특정 노드에 스케줄되기 위해서는 그 노드의 taint에 맞는 'toleration'을 가지고 있어야 합니다. Taint와 Toleration Taint: 노드에 적용되어, 특정 조건을 만족하지 않는 파드의 스케줄링을 방지합니다. Toleration: 파드에 적용되어, 특정 taint를 용인할 수 있음을 나타냅니다. toleration을 가진 파드는 해당 taint가 있는 노드에 스케줄될 수 있습니다. Taint의 구성 요소 Key: tain..