Content Comparison

...

• 지원하는 애플리케이션의 유형을 제약하지 않는다.

• 소스 코드를 배포하지 않으며 애플리케이션을 빌드하지 않는다.

• 애플리케이션 레벨의 서비스를 제공하지 않는다.

• 로깅, 모니터링 또는 경보 솔루션을 포함하지 않는다. 즉, 메트릭을 수집하고 노출하는 메커니즘을 제공한다.

• K8s는 단순한 오케스트레이션 시스템이 아니다. 사실, K8s는 오케스트레이션의 필요성을 없애준다. 오케스트레이션의 기술적인 정의는 A를 먼저 한 다음, B를 하고, C를 하는 것과 같이 정의된 워크플로우를 수행하는 것이다. 반면에, K8s는 독립적이고 조합 가능한 제어 프로세스들로 구성되어 있다. 이 프로세스는 지속적으로 현재 상태를 입력받은 의도한 상태로 나아가도록 한다. A에서 C로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필요치 않다. 이로써 시스템이 보다 더 사용하기 쉬워지고, 강력해지며, 견고하고, 회복력을 갖추게 되며, 확장 가능해진다.

...

• kubelet

  • cluster의 각 노드에서 실행되는 에이전트.
    Kubelet은 파드에서 컨테이너가 확실하게 동작하도록 관리.

  • Kubelet은 8s를 통해 생성되지 않는 컨테이너는 관리하지 않는다.

• kube-proxy

  • kube-proxy는 cluster의 각 노드에서 실행되는 네트워크 프록시로, K8s의 서비스 개념의 구현부

  • kube-proxy는 노드의 네트워크 규칙을 유지 관리한다. 이 네트워크 규칙이 내부 네트워크 세션이나 cluster 바깥에서 파드로 네트워크 통신을 할 수 있도록 해준다.

  • kube-proxy는 운영 체제에 가용한 패킷 필터링 계층이 있는 경우, 이를 사용한다. 그렇지 않으면, kube-proxy는 트래픽 자체를 포워드(forward)한다.

• Container runtime

  • 컨테이너 실행을 담당하는 소프트웨어

  •  도커(Docker), containerd, CRI-O 그리고 Kubernetes CRI (컨테이너 런타임 인터페이스)를 구현한 모든 소프트웨어 지원.

...

• DNS

  • K8s에 의해 구동되는 컨테이너는 DNS 검색에서 이 DNS 서버를 자동으로 포함한다

• 웹 UI (대시보드)

• 컨테이너 resource 모니터링

  • 컨테이너 resource 모니터링은 중앙 데이터베이스 내의 컨테이너들에 대한 포괄적인 시계열 매트릭스를 기록하고 그 데이터를 열람하기 위한 UI를 제공해 준다.

• cluster-레벨 로깅

  • cluster-레벨 로깅 메커니즘은 검색/열람 인터페이스와 함께 중앙 로그 저장소에 컨테이너 로그를 저장하는 책임을 진다.

Understanding Terms(중요)

...

emptyDir의 물리적으로 노드에서 할당해주는 디스크에 저장이 되는데, (각 환경에 따라 다르다. 노드의 로컬 디스크가 될 수 도 있고, 네트워크 디스크 등이 될 수 도 있다.) emptyDir.medium 필드에 “Memory”라고 지정해주면, emptyDir의 내용은 물리 디스크 대신 메모리에 저장이 된다.

만일 한 Pod 내에 Nginx 컨테이너 + fluentd(로그 수집 에이전트) 컨테이너 + emptyDir 볼륨이 있다면, 이 두 컨테이너는 할당된 emptyDir 볼륨을 공유하여 사용하게 된다.(메모리라 하더라도…)
또한 앞서 언급한 바와 같이, 생명 주기도 Pod에 따른다.

...

hostPath는 노드의 로컬 디스크의 directory path를 Pod에서 마운트해서 사용한다. emptyDir과 달리, 같은 hostPath에 있는 볼륨은 여러 Pod 사이에서 공유되어 사용된다.

또한  Pod가 삭제 되더라도 hostPath에 있는 파일들은 삭제되지 않고 다른 Pod가 같은 hostPath를 마운트하게 되면, 남아 있는 파일을 액세스할 수 있다.

...

이와 같이, 만일 NFS, FC, iSCSI와 같은 표준 스토리지 프로토콜이 아닌 경우에도, 현재 대부분의 클라우드 제공자, 가상화 제품 벤더사 및 스토리지 벤더사가 k8s addon을 이미 제공하고 있으며, 각각 제공하는 규격에 맞게 정의하면 된다.

Service

Service는 Service는 주로 네트워킹에 관련된 오브젝트이다.
물리적인 L2, L3 layer 네트워킹 뿐 아니라, DNS lookup, Service discovery, L4 layer load balancing 등 pod들 간 혹은 내/외부 간 다양한 네트워킹 서비스들을 정의/관장한다.
(해서, 가장 종류도 많고 어렵다)

예를 들어, Pod의 경우에 지정되는 IP가 동적으로 랜덤하게 지정이 되고 리스타트 때마다 변하기 때문에 고정된 end point로 호출이 어렵다, 또한 여러 Pod에 같은 애플리케이션을 운용할 경우 이 Pod 간의 로드밸런싱을 지원해줘야 하는데, 서비스가 Service가 이러한 역할을 한다.

서비스는 Service는 지정된 IP로 생성이 가능하고, 여러 Pod를 묶어서 로드밸런싱이 가능하며, 고유한 DNS 이름을 가질 수 있다.

서비스는 Service는 다음과 같이 구성이 가능하며, label selector를 이용하여, 관리하고자 하는 Pod 들을 정의할 수 있다. (또한 아래 예와 같이 동시에 여러 개의 포트 지정을 지원한다.)
즉, pod든 replica set이든, deployment든 간에 같은 label라면 해당(label selector에 지정된) 서비스에 Service에 묶는다.(아래의 경우는 “hello-node” label을 가진 pod들을 묶어서 80과 443 포트로 load balancing한다.)

apiVersion: v1
kind: Service
metadata:
  name: hello-node-svc
spec:
  selector:
    app: hello-node
  ports:
    - name: http
      port: 80
      protocol: TCP
      targetPort: 8080
    - name: https
      port: 443
      protocol: TCP
      targetPort: 8082
  type: LoadBalancer

서비스가 Service가 Pod들에 부하를 분산할 때, Default 알고리즘은 Pod 간에 랜덤으로 부하를 분산하도록 한다.
만약에 특정 클라이언트가 특정 Pod로 지속적으로 연결이 되게 하려면  Session Affinity를 사용하면 되는데, 서비스의 spec 부분에 sessionAffinity: ClientIP로 지정하면 된다.

서비스는 Service는 IP 주소 할당 방식과 연동 서비스 등에 따라 크게 4가지로 구별할 수 있다.

• ClusterIP: Default 설정으로, 서비스에 Service에 클러스터 IP (내부 IP)를 할당한다. K8s 클러스터 내에서는 이 서비스에 Service에 접근이 가능하지만, 클러스터 외부에서는 외부 IP를 할당 받지 못했기 때문에, 접근이 불가능하다.

• LoadBalancer: 보통의 클라우드 벤더에서 제공하는 설정 방식으로, 외부 IP를 가지고 있는 LoadBalancer를 할당한다. 외부 IP를 가지고 있기  때문에, 클러스터 외부에서 접근이 가능하다.
  NodePort: 클러스터 IP로만 접근이 가능한 것이 아니라, 모든 노드의 IP와 포트를 통해서도 접근이 가능하게 된다.
  예를 들어 아래와 같이 단, 외부 서비스를 위해 externalIPs를 지정해주어야 하는데, 이는 k8s에서 관리하지 않는다. 즉, 외부 loadbalancer(HAProxy 등)나 Cloud 환경이라면 Cloud 벤더에서 제공하는 loadbalancer의 IP를 별도 지정해주어야 한다.
  또한, 일부 클라우드 공급자는 loadBalancerIP를 지정할 수 있도록 허용하며, 클라우드 공급자가 이 기능을 지원하지 않는 경우, 설정한 loadbalancerIP 필드는 무시된다.

• NodePort: 클러스터 IP로만 접근이 가능한 것이 아니라, 모든 노드의 IP와 포트를 통해서도 접근이 가능하게 된다.
  예를 들어 아래와 같이 hello-node-svc 라는 서비스를 Service를 NodePort 타입으로 선언을 하고, nodePort를 30036으로 설정하면, 아래 설정에 따라 클러스터 IP의  80포트로도 접근이 가능하지만, 모든 노드의 30036 포트로도 서비스를 접근할 수 있다.

  Image RemovedImage Added

  주의할 점은 위의 80 포트도 cluster IP이기 때문에 Cluster 내에서만 접속이 가능하다.
  즉, 위의 ClusterIP + “각 노드에 port forwarding” 기능이라 생각하면 무리가 없을 것이다.

• ExternalName: ExternalName은 외부 서비스를 k8s 내부에서 호출하고자 할 때 사용할 수 있다.

  K8s cluster 내의 Pod들은 클러스터 IP를 가지고 있기 때문에 - 즉, 외부로 통하는 gateway를 가지고 있지 않다 - 클러스터 IP 대역 밖의 서비스를 호출하고자 하면, NAT 설정 등의 복잡한 설정이 필요하다.

  특히, AWS나 GCP와 같은 클라우드 환경을 사용할 경우 DB나, 또는 클라우드에서 제공되는 매지니드 서비스(RDS, CloudSQL)등을 사용하고자 할 경우에는 k8s 클러스터 밖이기 때문에, 호출이 어려운 경우가 있는데, 이를 쉽게 해결할 수 있는 방법이 ExternalName 타입이다.
  
  이 방식도 다시 두 가지 방식으로 설정할 수 있는데,
  첫 번째는 DNS 방식이고, 두 번째는 IP를 지정하는 방식이다.
  
  DNS 방식은 Service object의 spec에 아래와 같이
   type: ExternalName
 externalName: my.database.example.com

  ExternalName과 함께 직접 지정하면 되고, 이 Service는 들어오는 모든 요청을 “my.database.example.com”으로 forwarding 해준다.

  Image RemovedImage Added

  IP를 지정하는 방식은 ClusterIP로 service를 Service를 하나 생성하고, Endpoints라고 하는 object를 하나 더 생성하여, forwarding될 IP와 port를 지정하고 이를 연결하여 사용한다.
  그림으로 나타내면 다음과 같다.

  Image RemovedImage Added

Ingress

URL path/http(s) 기반 L7 layer routing/load balancing …to doK8s의 Service는, L4 레이어로 TCP 단에서 Pod들을 balancing한다.

Service의 경우에는 TLS (SSL)이나, VirtualHost와 같이 여러 호스트명을 사용하거나 호스트명에 대한 라우팅이 불가능하고, URL Path에 따른 서비스 간 라우팅이 불가능하다.
또한 마이크로 서비스 아키텍쳐 (MSA)의 경우에는 k8s의 Service 하나가 MSA의 하위 서비스 하나로 표현되는 경우가 많고 전체 서비스는 하나의 URL로 대표 되는 경우가 많다. (/users, /products, …)

그래서 MSA 서비스간의 라우팅을 하기 위해서는 API Gateway를 넣는 경우가 많은데, 이 경우에는 API Gateway에 대한 관리 포인트가 생기기 때문에, URL 기반의 라우팅 정도라면, API 게이트웨이처럼 무거운 아키텍쳐 컴포넌트가 아니라, L7 로드밸런서 정도로 위의 기능을 모두 제공이 가능하다.
(사실, MSA에서의 API Gateway는 L7 라우팅 역할 외에도 사용자 보안 인증 및 권한에 따른 토큰 관리 등 Kong과 같은 상업적 제품이 따로 존재할 정도로 전체 서비스를 위한 대문(Gateway)으로서 하는 일이 아주 많다.)

K8s에서 HTTP(S)기반의 L7 로드밸런싱 기능을 제공하는 컴포넌트를 Ingress라고 한다.

개념을 도식화 해보면 아래와 같은데, Ingress 가 서비스 앞에서 L7 로드밸런서 역할을 하고, URL에 따라서 라우팅을 하게 되며, Service는 L4 로드밸런서 역할을 하게 된다.

...

여러 네트워크 서비스와 같이, Ingress도 여러가지 3rd party addon 구현체가 존재하며,
Ingress 리소스가 작동하려면, 클러스터는 실행 중인 Ingress 컨트롤러가 반드시 필요하다.

kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의 다른 타입과 달리 Ingress 컨트롤러는 클러스터와 함께 자동으로 실행되지 않는다. 클러스터에 가장 적합한 Ingress 컨트롤러 구현을 선택한다.

k8s는 자체 서브 프로젝트로써 현재 GCE 와 nginx 컨트롤러를 지원하고 유지한다.

이외에도 다음과 같은 추가 컨트롤러를 사용할 수 있다.

• AKS Application Gateway Ingress Controller is an ingress controller that enables ingress to AKS clusters using the Azure Application Gateway.

• Ambassador API 게이트웨이는 Datawire의 커뮤니티 혹은 상업적 지원을 제공하는 Envoy 기반 인그레스 컨트롤러다.

• AppsCode Inc. 는 가장 널리 사용되는 HAProxy 기반 인그레스 컨트롤러인 Voyager에 대한 지원 및 유지 보수를 제공한다.

• AWS ALB 인그레스 컨트롤러는 AWS Application Load Balancer를 사용하여 인그레스를 활성화한다.

• Contour는 Envoy 기반 인그레스 컨트롤러로 VMware에서 제공하고 지원한다.

• Citrix는 베어메탈과 클라우드 배포를 위해 하드웨어 (MPX), 가상화 (VPX) 및 무료 컨테이너화 (CPX) ADC를 위한 인그레스 컨트롤러를 제공한다.

• F5 Networks는 쿠버네티스를 위한 F5 BIG-IP 컨테이너 인그레스 서비스에 대한 지원과 유지 보수를 제공한다.

• Gloo는 solo.io의 엔터프라이즈 지원과 함께 API 게이트웨이 기능을 제공하는 Envoy 기반의 오픈 소스 인그레스 컨트롤러다.

• HAProxy 인그레스는 HAProxy를 위한 고도로 커스터마이징 가능한 커뮤니티 주도형 인그레스 컨트롤러다.

• HAProxy Technologies는 쿠버네티스를 위한 HAProxy 인그레스 컨트롤러를 지원하고 유지 보수한다. 공식 문서를 통해 확인할 수 있다.

• Istio는 인그레스 컨트롤러 기반으로 인그레스 트래픽을 제어.

• Kong은 오픈소스 API Gateway이며, 쿠버네티스를 위한 Kong 인그레스 컨트롤러에 대한 커뮤니티 또는 상업적 지원과 유지 보수를 제공한다.

• NGINX, Inc.는 쿠버네티스를 위한 NGINX 인그레스 컨트롤러에 대한 지원과 유지 보수를 제공한다.

• Skipper는 쿠버네티스 인그레스와 같은 유스케이스를 포함하는 서비스 구성을 위한 HTTP 라우터와 리버스 프록시는 사용자 정의 프록시를 빌드하기 위한 라이브러리로 설계되었다.

• Traefik은 모든 기능(Let's Encrypt, secrets, http2, 웹 소켓)을 갖춘 인그레스 컨트롤러로, Containous에서 상업적인 지원을 제공한다.

Config Map

Secret

Service Account

...