live the life you love

현재 설치된 Kubernetes Cluster의 정보, context, user의 정보가 Config map으로 .kube/config에 저장되어 있다. 유저를 추가하거나, 클러스터를 추가하면 해당부분에 자동으로 추가가 된다. 더이상 안쓰는 클러스터, 유저를 삭제하려면 아래와 같은 명령어로 삭제가 가능하다. config파일은 굳이 수동으로 지우는것은 권장되지 않는다. kubectl config unset PROPERTY_NAME [options] # 클러스터 삭제(실제로 삭제는 아니고 여기서 연결을 끊는 것) kubectl config unset clusters.cluster_name # 컨텍스트 삭제 kubectl config unset contexts.context_name # 유저 삭제 kubect..

Pod의 남은 리소스가 부족한 경우, Pod는 다운되버린다. 하지만 Pod는 중요도가 각기 다르기 때문에, 중요한 Pod가 죽어버리면 서비스에 큰 문제가 생길 수 있다. 그렇기 때문에 상대적으로 중요도가 낮은 다른 Pod를 down 시키고 그만큼의 리소스를 중요도가 높은 Pod에 할당 할 수 있다. 쿠버네티스가 Pod를 생성할 때 다음의 3가지 QoS 클래스 중 하나를 할당한다. 각각을 명시적으로 설정할 수는 없고 컨테이너에 정의된 resources의 request, limits에 따라 쿠버네티스가 알아서 클래스를 적용해주는 것이다. Guranteed(가장 나중에 삭제) 모든 Container에 Request와 Limit가 설정되야 한다. Request와 Limit에는 Memory와 CPU가 모두 설정되..

Pod의 기본적인 라이프 사이클 Pending → Running → Succeeded → Failed Pending : 파드가 쿠버네티스 클러스터에서 승인되었지만 아직 컨테이너가 설정되지 않았음. 네트워크를 통한 컨테이너 이미지 다운로드 시간도 포함 Probe Probe의 상태 : Success, Failure, Unknown startupProbe : 어플리케이션이 시작 되었는지를 판단 startupProbe를 세팅한 경우, startupProbe가 OK신호를 보내줘야 readinessProbe 와 livenessProbe가 돌아간다. readinessProbe : 컨테이너가 요청을 처리할 준비가 되었는지 Pod가 새로 배포되고 Running 상태여도 그 안에 있는 컨테이너에서 배포되는 어플리케이션도 ..

Controller Controller의 기능 Auto Healing Pod가 죽었을 때, 이 Pod를 다른 Node위에 새로 만들어준다. Auto Scaling Pod의 리소스 상태가 limit가 되었을 때, Controller가 Pod를 하나 더 만들어서 리소스의 부하를 낮춰준다. Software Update 여러 Pod에 대한 버전을 업데이트 하는 경우, 한번에 업데이트 가능 업데이트 중 문제가 생기면 롤백도 가능 Job 일시적인 작업을 해야하는 경우 그 순간에만 Pod(Job)을 만들어서 작업을 하고 삭제를한다. 그 순간에만 일시적으로 리소스를 늘렸다가 삭제하기 때문에 효율적인 리소스 활용 가능 ReplicationController ReplicationController는 Deprecated 되..

Kind- apiVersion CertificateSigningRequest certificates.k8s.io/v1beta1 ClusterRoleBinding rbac.authorization.k8s.io/v1 ClusterRole rbac.authorization.k8s.io/v1 ComponentStatus v1 ConfigMap v1 ControllerRevision apps/v1 CronJob batch/v1beta1 DaemonSet apps/v1 Deployment apps/v1 Endpoints v1 Event v1 HorizontalPodAutoscaler autoscaling/v1 Ingress extensions/v1beta1 Job batch/v1 LimitRange v1 Names..

쿠버네티스 클러스터 안에는 여러개의 네임스페이스를 만들 수 있다. 또한, 하나의 네임스페이스 안에는 여러개의 파드를 만들 수 있다. 각 파드들은 하나의 클러스터 내부에 있는 자원을 공유해서 사용한다. 이때 특정 파드에서 너무 많은 자원을 사용하면 다른 네임스페이스에 있는 파드들이 리소스를 사용하지 못하므로 이것을 방지하기 위해서 네임스페이스 마다 resource quota를 할당할 수 있다. 또한, LimitRange를 둬서 네임스페이스에 두는 Pod의 크기를 제한할 수 있다. Namespace 같은 네임스페이스 안에서 오브젝트 끼리의 이름은 겹칠 수 없다. Pod와 Service의 네임스페이스가 서로 다르면, Selector로 묶을 수 없다. 서로 다른 Namespace에서 통신이 가능하지만 통신을 막..

ConfigMap, Secret 개발환경과 운영환경이 다르다면 이미지를 만들 때 들어가는 설정들이 조금씩 다른 경우가 있다. 예를 들어, 개발환경에서는 SSH 접속을 가능하게 하고, 접근 유저와 키 값을 세팅할 수 있다. 반면 운영 환경에서는 SSH 접속을 불가능하게 해야한다. Service의 이미지로 만들어서 배포한다고 하면 이 정보만 수정하기 위해 이미지를 운영환경과 개발환경에서 각각 2개를 만들어 하고, 이는 관리의 어려움과 번거로움이 생길 수 있다. 이러한 설정 정보들을 따로 관리해 주는 것이 ConfigMap과 Secret이다. 컨테이너를 만들 때 ENV값에 넣어준다. Secret은 Base64 인코딩을 해서 저장해야 하고, 이를 파드에 배포하면 알아서 디코딩 해준다. secret에 Base64..

emptyDir Pod내의 컨테이너들끼리 데이터를 공유하기 위해 볼륨을 사용 볼륨은 Pod내에 위치한다. 최초에 생성할 때는 볼륨이 비어있는 상태이다. Pod안에 볼륨이 생성되기 때문에, Pod가 사라질 때 같이 사라진다. hostPath 자신(Pod)이 올라가 있는 Node의 path를 볼륨으로 사용 개별 노드를 위한 파일들을 관리하는데 용이함 Node의 파일 시스템을 접근하는데 유용하다. ex) 노드의 로그 파일을 읽어서 수집하는 용도 Pod들이 죽어도 볼륨은 사라지지 않는다. 만약 Node가 2개 이상일 경우 Pod가 다른 Node에 재생성되면 기존 Node에 볼륨마운트를 할 수 없으므로 문제가 생긴다. hostPath에 정의된 path는 Pod가 생성되기 전에 만들어져 있어야 한다 단, type ..

Pod내의 컨테이너에 접속하기 # Deprecated $ kubectl exec -it [Pod_Name] /bin/bash # Recommended $ kubctl exec -it [Pod_Name] -- bash Namespace 확인, 생성, 교체 $ kubectl create ns {namespace_name} # 생성 $ kubectl get ns # 확인 $ kubectl config set-context --current --namespace={namespace_name} # 현 위치에서 namespace 변경 Node에 태그 붙이기 # kubectl label nodes [node 이름] [key=value] $ kubectl label nodes aks-agentpool-19228959-..

인프런에서 쿠버네티스 강의를 듣는데, 강의 환경은 VM 3개를 띄워서 1대는 마스터 노드, 나머지 2대는 워커노드로 사용을 한다. 이번 강의에서 실습한 내용은 아래와 같다 Pod에 Service를 붙이기 Master Node에서 curl로 Cluster IP를 호출한다 해당 IP의 9000번 포트에 접근하여 hostname을 url 매개변수로 넘겨주면 9000번 포트에 올라가 있는 Pod의 호스트 네임이 출력된다. (Pod의 이미지의 내용이 이렇다) 우선 각 오브젝트들의 매니페스트 정보는 다음과 같다 pod.yaml apiVersion: v1 kind: Pod metadata: name: pod-1 labels: app: pod spec: nodeSelector: kubernetes.io/hostname..