출항사

What is Ingress? Kubernetes Ingress는 kubernetes cluster 내부에 존재하는 여러 service들을 cluster 외부의 client에게 HTTP, HTTPS로 노출하도록 도와준다. Ingress는 cluster 내부의 여러 service들을 하나의 virtual IP address에 매핑하고, service에 접근하고자 하는 client들은 이 virtual IP address를 통해 service에 access할 수 있게 된다. Kubernetes Ingress를 통해 service에 접근하는 flow를 그림으로 나타내면 아래와 같다. Ingress는 또한 Load Balancing, SSL 인증서 관리, Cache, 방화벽 설정 등의 기능을 제공하여 Clien..

도커나 도커 스웜 모드를 사용할 때에는 컨테이너를 논리적으로 구분하는 방법이 없었다. 그래서 용도에 따라 컨테이너와 그에 관련된 리소스들을 구분 지어 관리할 수 있는 일종의 논리적인 그룹이 있으면 좀 더 편할 것이다. 쿠버네티스에서는 리소스를 논리적으로 구분하기 위해 네임스페이스(Namespace)라는 오브젝트를 제공한다. 간단히 생각해 네임스페이스는 파드, 레플리카셋, 디플로이먼트, 서비스 등과 같은 쿠버네티스 리소스들이 묶여 있는 하나의 가상 공간 또는 그룹이라고 생각하면 된다. 예를들어 모니터링을 위한 모든 리소스들을 monitoring이라는 이름의 네임스페이스에서 생성할 수 있고, 테스트를 위한 리소스들은 testbed라는 네임스페이스에서 생성할 수 있다. 또는 여러 개발 조직이 하나의 쿠버네티스..

이전까지 쿠버네티스에서 컨테이너를 구성하는 가장 중요한 요소인 파드, 레플리카셋, 그리고 디플로이먼트에 대해서 알아봤다. 그러나 디플로이먼트를 통해 생성된 파드에 어떻게 접근할 수 있을지에 대해서는 아직 알아보지 않았다. 이전에는 kubectl describe 명령어로 파드의 내부 IP를 직접 확인한 뒤 파드로 직접 접근할 수는 있었지만, 이 방법은 로컬 개발 환경 또는 쿠버네티스 클러스터 내부에서만 사용할 수 있었다. 게다가 도커 컨테이너와 마찬가지로 파드의 IP는 영속적이지 않아 항상 변할 수 있다는 점도 유의해야 한다. 여러 개의 디플로이먼트를 하나의 완벽한 애플리케이션으로 연동하려면 파드 IP가 아닌, 서로를 발견(Discovery)할 수 있는 다른 방법이 필요하다. 도커 컨테이너는 -p 옵션으로..

디플로이먼트 사용하기 레플리카셋만 사용해도 충분히 Micro Service 구조의 컨테이너를 구성할 수 있을 것 같지만, 실제 쿠버네티스 운영 환경에서 레플리카셋을 YAML 파일에서 사용하는 경우는 거의 없다. 대부분은 레플리카셋과 파드의 정보를 정의하는 '디플로이먼트(Deployment)'라는 이름의 오브젝트를 YAML 파일에 정의해 사용한다. 디플로이먼트는 레플리카셋의 상위 오브젝트이기 때문에 디플로이먼트를 생성하면 해당 디플로이먼트에 대응하는 레플리카셋도 함께 생성된다. 따라서 디플로이먼트를 사용하면 파드와 레플리카셋을 직접 생성할 필요가 없다. 간단한 예시를 통해 디플로이먼트를 직접 생성해 보자. apiVersion: apps/v1 kind: Deployment metadata: name: my-..

레플리카셋을 사용하는 이유 쿠버네티스의 기본 단위인 파드는 여러 개의 컨테이너를 추상화해 하나의 애플리케이션으로 동작하도록 만드는 컨테이너 묶음이다. 그러나 YAML에 파드를 생성하게 되면 이 파드의 생성 주기는 어떻게 될까? YAML로 생성한 파드는 아래와 같은 두 가지 방법으로 삭제할 수 있다. kubectl delete -f nginx-pod-with-ubuntu.yaml kubectl delete pods my-nginx-pod 만약 kubectl delete 명령어로 파드를 삭제하면 파드의 컨테이너 또한 삭제된 뒤 쿠버네티스에서 영원히 사라지게 된다. 이처럼 YAML 파일에 파드만 정의해 생성할 경우 해당 파드는 오직 쿠버네티스 사용자에 의해 관리된다. 단순히 파드의 기능을 테스트하는 등의 간단..

쿠버네티스를 도커 스웜 모드와 비교해 봤을 때, 쿠버네티스만이 가지는 고유한 특징이 있다. 모든 리소스는 오브젝트 형태로 관리된다. 쿠버네티스는 대부분의 리소스를 '오브젝트'라고 불리는 형태로 관리한다. 그리고 이 오브젝트라는 용어는 흔히 알고 있는 추상화된 집합에서 크게 벗어나지 않는 개념이다. 도커 스웜을 사용할 때, 컨테이너의 묶음을 표현하기 위해 '서비스(service)'라는 것을 사용했었다. 스웜 모드의 서비스도 컨테이너 리소스의 집합을 정의한 것이기 때문에 일종의 오브젝트라고 볼 수 있다. 그러나 쿠버네티스는 이러한 개념을 더욱 폭넓고 세밀한 단위로 사용한다. 예를 들어 쿠버네티스에서는 컨테이너의 집합(Pods), 컨테이너의 집합을 관리하는 컨트롤러(Replica Set), 사용자(Servic..