kubernetes

Kubernetes Architecture – From Docker Images to Running Pods 이번 chapter에서 배울 것은 다음과 같다. master 노드와 worker 노드의 차이 kube-apiserver component kubectl cli

이미 이전에 pod는 관련된 container들의 그룹으로 kubernetes에서 가장 기본적인 building block을 구성한다고 하였다. pod안에 container 몇 개 있는 것인지는 중요하지 않다. 중요한 것은 각 worker node에서 pod들을 공유하

하나의 pod에 여러 개의 container들을 구동할 수 있다. 즉, pod는 여러 개의 container들을 한꺼번에 관리할 수 있는 것이다. 하나의 pod에 여러개의 container들을 올리는 여러 가지 방법들을 배워보고 container들끼리 어떻게 통신할 수

이번 chapter에서는 ConfigMaps와 Secrets라는 kubernetes object에 대해서 알아보도록 한다.kubernetes에서는 configuration을 가장 중요한 요소로 생각하여 두 가지 resource를 만들어냈다. 하나는 ConfigMaps이

pod를 end user에게 접근 가능하게하고, 다른 pod들끼리 통신하도록 만들고 싶을 것이다. 이러한 것들을 가능하게 해주는 것이 바로 kubernetes의 Services이다.kubernetes는 pod가 배포되면 자동적으로 cluster에 사용할 수 있는 pri

ReadinessProbe와 LivenessProbe는 end user에게 application을 제공하기 위해서는 필수와도 같은 존재이다. ReadinessProbe를 먼저 구현해보도록 하고, 이를 통해 우리의 container들이 traffic을 받아들일 준비가 되

이번에는 namespace에 대해서 알아보자. namespace는 application 또는 environment에 따라 우리의 cluster resource들을 그룹화하여 잘 관리해주도록 도와준다.kubernetes cluster에 application이 많아지면 많

pod를 실행하고 계속해서 관리하는 데 있어서, 개발자가 직접 제어하는 것은 매우 번거로운 일이다. 자동으로 pod가 배포되고, 다운되면 다시 살려주는 리소스가 있으면 kubernetes 클러스터를 관리하는데 매우 쉬울 것이다. replication controller

Service는 kubernetes 리소스로 pod에 접근하기 위한 IP주소를 제공한다. pod자체에 IP가 존재하는데 불구하고 Service를 만들어 사용하는 이유가 무엇일까?? pod는 일시적이다. 언제든 재시작될 수 있으며 재시작되면 이전의 IP주소가 아닌 새로운

pod의 하나의 개별 host와 같다. CPU와 Memory를 할당받고 개개의 네트워크 인터페이스를 가지며, 하나의 독립적인 host machine처럼 동작한다. disk의 경우도 마찬가지이다. 각 pod들은 개별 filesystem을 가지기 때문에 pod가 재시작되면

kubernetes는 각 pod의 container마다 custom 환경변수를 설정할 수 있도록 해준다.Note: container를 실행할 때 ENTRYPOINT등의 설정을 kubernetes에서 command, args라는 keyword로 오버라이드가 가능하다. 마

pod가 만들어지기 전의 데이터들, 가령 pod이름, pod가 배치된 node, pod-ip, label, annotation들을 어떻게 알 수 있을까??이런 데이터에 접근할 수 있도록 하는 것이 바로 kubernetes의 downward API이다. downwared

kubernetes version을 1.18에서 1.28로 업그레이드한 뒤에 operator를 빌드하여 배포했더니 error가 발생했다. 왜 ErrImagePull이 발생했다. version up이 되어 이제는 container runtime을 dockershim이 아