Kubernetes in Google Cloud #3

Orchestrating the Cloud with Kubernetes

 

Kubernetes를 통한 클라우드 조정 | Google Cloud Skills Boost

 

 

Pod 이라는 개념을 새로 알게 되었다.

 

기본적으로 container가 각자 고유한 namespace를 가지는 것으로 알고 있었는데 역시 이론과 실제는 다른 것 같다.

 

서로 깊게 dependancy가 있다거나 할 때, 그러한 container들을 하나의 pod에 넣는다고 한다.

 

하나의 pod 안에는 속해있는 container들이 공유하는 volume이라는 저장 공간이 있다.

 

기본적으로 pod은 외부와 단절되어 있는데 현재 local의 포트를 pod의 포트와 연결하여 외부에서 접속할 수 있도록 할 수 있다.

 

 

 

당연하지만 pod은 죽을 수 있다.

 

이를 되살려내도 같은 IP를 가진다는 보장이 없으므로 어떤 지속적인 서비스를 pod으로 제공하는 것은 힘들 것이다.

 

이러한 문제를 해결하기 위해 service가 등장한다.

 

service는 운영하고 있는 각 pod에 대해 label을 붙이고 pod이 올바른 label을 가지고 있다면 자동으로 노출시킨다.

 

3가지 type의 service가 있다.

 

- ClusterIP (internal): service가 cluster 안에서만 보인다. (default)

 

- NodePort: cluster 안 각 노드에 외부에서 접근할 수 있는 IP를 부여한다.

 

- LoadBalancer: traffic을 보내는 load balancer를 추가한다.

 

아래의 블로그의 그림이 이해하기 쉽게 정리되어 있다.

 

[발번역] Kubernetes NodePort vs LoadBalancer vs Ingress?? 언제 무엇을 써야 할까??

 

 

포트를 임의로 할당할 때 다른 app과 충돌할 수 있는데 이를 check하는 기능도 있다고 한다.

 

 

 

 

이번 랩의 목표는 container들을 scaling하고 관리하는 것이다.

 

Deployment는 그러한 역할을 하는데 low level의 세세한 디테일을 생각할 필요 없이 추상화되어있다는 점이 장점이다.

 

만약 node3이 죽었다면 새로운 pod을 node2에서 돌아가도록 하는 방법을 사용한다.

(새로운 pod을 생성해서 그 pod을 실행시킬 node를 찾는 대신)