쿠버 정리 #2

Service

쿠버네티스 환경에서 서비스(Service)는 파드들을 통해 실행되고 있는 애플리케이션을 네트워크에 노출(expose)시키는 가상의 컴포넌트다.

쿠버네티스 내부의 다양한 객체들이 애플리케이션과, 그리고 애플리케이션이 다른 외부의 애플리케이션이나 사용자와 연결될 수 있도록 도와주는 역할을 한다.

쿠버네티스에서의 파드는 무언가가 구동 중인 상태를 유지하기 위해 동원되는 일회성 자원으로 언제든 다른 노드로 옮겨지거나 삭제될 수 있다. 또한 파드는 생성될 때마다 새로운 내부 IP를 받게 되므로, 이것만으로 클러스터 내/외부와 통신을 계속 유지하기는 어렵다.

쿠버네티스에서는 파드가 외부와 통신할 수 있도록 클러스터 내부에서 고정적인 IP를 갖는 서비스(Service)를 이용하도록 하고 있다. 

서비스를 정의하고 생성할 때에는 spec.ports 아래에 연결하고자 하는 항목 별로 각각 2개씩의 포트가 지정되어야 한다. 아래의 항목 명칭은 클러스터 안에서 트래픽을 중계하는 서비스의 입장에서 기술된 것임을 이해하자.

• targetPort : 파드의 애플리케이션 쪽에서 열려있는 포트를 의미한다. 서비스로 들어온 트래픽은 해당 파드의 <클러스터 내부 IP>:<targetPort>로 넘어가게 된다.
• port : 서비스 쪽에서 해당 파드를 향해 열려있는 포트를 의미한다.

서비스 유형

1. ClusterIP (기본 형태)
2. NodePort
3. LoadBalancer
4. ExternalName

ClusterIP

ClusterIP는 파드들이 클러스터 내부의 다른 리소스들과 통신할 수 있도록 해주는 가상의 클러스터 전용 IP다. 이 유형의 서비스는 <ClusterIP>로 들어온 클러스터 내부 트래픽을 해당 파드의 <파드IP>:<targetPort>로 넘겨주도록 동작하므로, 오직 클러스터 내부에서만 접근 가능하게 된다. 쿠버네티스가 지원하는 기본적인 형태의 서비스다.

NodePort

NodePort는 외부에서 노드 IP의 특정 포트(<NodeIP>:<NodePort>)로 들어오는 요청을 감지하여, 해당 포트와 연결된 파드로 트래픽을 전달하는 유형의 서비스다. 이때 클러스터 내부로 들어온 트래픽을 특정 파드로 연결하기 위한 ClusterIP 역시 자동으로 생성된다.

LoadBalancer

도의 외부 로드 밸런서를 제공하는 클라우드(AWS, Azure, GCP 등) 환경을 고려하여, 해당 로드 밸런서를 클러스터의 서비스로 프로비저닝할 수 있는 LoadBalancer 유형도 제공된다.

ExternalName

서비스에 selector 대신 DNS name을 직접 명시하고자 할 때에 쓰인다. spec.externalName 항목에 필요한 DNS 주소를 기입하면, 클러스터의 DNS 서비스가 해당 주소에 대한 CNAME 레코드를 반환하게 된다.

CNI 

컨테이너 간의 네트워킹을 제어할 수 있는 플러그인을 만들기 위한 표준입니다.

쿠버네티스에서는 Pod 간의 통신을 위해서 CNI 를 사용합니다. 

CNI는 Calico, Weavenet, AWS CNI 등 매우 다양한 종류가 있습니다.

https://captcha.tistory.com/78

CNI에서 사용되는 네트워크 모델

CNI Provider는 VXLAN(Virtual Extensible Lan), IP-in-IP 과 같은 캡슐화된 네트워크 모델 또는 BGP (Border Gateway Protocol)와 같은 캡슐화 되지 않은 네트워크 모델을 사용하여 네트워크 패브릭을 구현합니다. 

 

쿠버네티스는 모든 네트워킹 구현에 대해 다음과 같은 근본적인 요구사항을 만족할 것을 요구한다. (이를 통해, 의도적인 네트워크 분할 정책을 방지)

• 파드는 NAT 없이 노드 상의 모든 파드와 통신할 수 있다.
• 노드 상의 에이전트(예: 시스템 데몬, kubelet)는 해당 노드의 모든 파드와 통신할 수 있다.

Namespaces

• 도커에서의 Namespace와는 다른 개념이다
  • 도커에서의 Namespace는 호스트 내에서 Namespace로 분리하여 독립적인 리소스를 할당받아서 관리할 수 있는 개념이다
• 쿠버네티스에서의 Namespace는 하나의 Control Plane(Master)와 Worker Node들을 하나의 독립적인 Namespace로 관리한다.

쿠버네티스에서, 네임스페이스 는 단일 클러스터 내에서의 리소스 그룹 격리 메커니즘을 제공한다. 리소스의 이름은 네임스페이스 내에서 유일해야 하며, 네임스페이스 간에서 유일할 필요는 없다. 네임스페이스 기반 스코핑은 네임스페이스 기반 오브젝트 (예: 디플로이먼트, 서비스 등) 에만 적용 가능하며 클러스터 범위의 오브젝트 (예: 스토리지클래스, 노드, 퍼시스턴트볼륨 등) 에는 적용 불가능하다

• 리소스를 논리적으로 나누기 위한 방법을 제공하는 것
• Pod, Deployment, Service와 같은 여러 오브젝트들을 하나의 Namespace로 그룹핑해서 관리 할 수 있다.

namespace는 많은 사용자가 여러 팀 또는 프로젝트에 분산되 었는 환경에서 사용하기 위한 것입니다.
사용자가 몇 명에서 수십 명에 이르는 kubernetes cluster의 경우 새롭게 namespaces를 생성할 필
요가 없으며, default-cluster 로 충분합니다.

Labels을 사용하여 동일한 Namespace 내의 resource를 구별 할 수 있습니다.

Pod 생성 및 컨테이너 구성 확인

• **kubectl api-resources**는 Kubernetes 클러스터 내에서 사용 가능한 API 리소스 목록을 보여주는 명령어입니다. Kubernetes API는 클러스터 내의 다양한 개체(object)를 관리하는 데 사용되며, 이 명령어를 통해 어떤 종류의 리소스가 사용 가능한지, 그리고 해당 리소스의 종류와 버전을 확인할 수 있습니다.
• kubectl api-resources 명령어는 다음과 같은 정보를 제공합니다:
  1. 이름 (Name): 리소스의 종류를 나타내는 문자열입니다. 예를 들어, "pods", "services", "deployments" 등이 리소스 이름의 예시입니다.
  2. 짧은 이름 (Short Names): 리소스에 대해 짧은 이름의 약어를 제공합니다. 이를 사용하여 리소스를 더 간단하게 참조할 수 있습니다.
  3. API 그룹 (API Group): Kubernetes API는 여러 그룹으로 나누어질 수 있습니다. 대부분의 리소스는 "core" 그룹에 속하며, 이 외에도 커스텀 리소스 정의를 통해 사용자 지정 그룹을 만들 수 있습니다.
  4. 버전 (Version): 리소스의 API 버전을 나타냅니다. Kubernetes는 API 버전 관리를 통해 업그레이드 및 호환성을 유지합니다.
  5. 리소스 타입 (Resource Type): 리소스의 유형을 나타냅니다. 예를 들어 "namespaces", "pods", "services" 등이 리소스 타입의 예시입니다.
• kubectl api-resources 명령어를 실행하면 현재 사용 가능한 모든 API 리소스의 목록이 표시됩니다. 이를 통해 클러스터 내의 다양한 리소스를 살펴보고, 해당 리소스에 대한 자세한 정보나 명령어를 실행하여 상호작용할 수 있습니다.

쿠버네티스 Pod 생성 실습

myweb.yaml : nginx 이미지를 사용하는 컨테이너를 생성한다.

apiVersion: v1 // stable release API 기본 Pod 생성시 쓰는 api
kind: Pod // 리소스 종류 Pod를 쓴다.
metadata: // pod의 이름과 라벨을 ㅇ지정
  name: myweb // pod 이름은 myweb
spec: // Pod에서 실행될 컨테이너의 스펙
  containers: // 컨테이너 정보
  - image: nginx:latest //사용할 이미지
    name: myweb-container // 컨테이너 이름
    ports: // 사용할 포트
    - containerPort: 80 // 80번 포트 오픈
      protocol: TCP // TCP로 통신

nginx 및 netshoot 컨테이너 생성하여 서로 통신하기

apiVersion: v1
kind: Pod
metadata:
  name: myweb2
spec:
  containers:
  - name: myweb2-nginx
    image: nginx
    ports:
    - containerPort: 80
      protocol: TCP

  - name: myweb2-netshoot // 2번째 컨테이너 이름
    image: nicolaka/netshoot // 2번째 컨테이너 이미지
# netshoot : 네트워크 관련 유틸이 설치된 이미지
    command: ["/bin/bash"]
    args: ["-c", "while true; do sleep 5; curl localhost; done"]
# /bin/bash로 5초 간격으로 웹 페이지를 접속하도록 설정

로그 기록을 통해 확인 가능

• f 또는 -follow: 로그를 실시간으로 스트리밍하는 옵션입니다. 새로운 로그 메시지가 기록될 때마다 계속해서 출력됩니다.
• c <container-name> 또는 -container=<container-name>: 컨테이너의 이름을 지정하는 옵션입니다. 만약 Pod 내에 여러 개의 컨테이너가 있는 경우, 이 옵션을 사용하여 특정 컨테이너의 로그를 확인할 수 있습니다.

Pause 컨테이너

• 역할: Pause 컨테이너는 파드의 네트워크 네임스페이스를 공유하며, 파드 내의 다른 컨테이너들이 공유하는 리눅스 네임스페이스를 유지합니다. 이 컨테이너는 실제 응용프로그램을 실행하지 않고, 단지 네트워크 및 네임스페이스 관리를 위한 역할을 합니다.
• 통신: 파드 내의 다른 컨테이너들은 공유하는 Pause 컨테이너를 통해 네트워크 통신을 할 수 있습니다. Pause 컨테이너를 통해 파드 내부의 모든 컨테이너는 동일한 IP 주소 범위를 공유하며, localhost를 통해 통신할 수 있습니다.

• 파드 내의 컨테이너들이 동일한 IP 주소를 가지는 주된 이유는 다음과 같습니다:
  1. Pause 컨테이너를 공유: 파드 내의 모든 컨테이너, 포함하여 일반적인 애플리케이션 컨테이너들, Pause 컨테이너를 공유합니다. Pause 컨테이너는 파드의 네트워크 네임스페이스를 관리하고, 모든 컨테이너가 동일한 네트워크 네임스페이스 내에서 실행됩니다.
  2. 네트워크 네임스페이스 공유: 파드 내의 모든 컨테이너들은 같은 네트워크 네임스페이스를 공유합니다. 이는 네트워크 주소 공간을 파드 단위로 격리하지 않고, 파드 내의 컨테이너들이 동일한 IP 범위와 서브넷을 공유하도록 함으로써 이루어집니다.
  3. 로컬호스트 통신: 파드 내의 컨테이너들은 로컬호스트 주소(127.0.0.1)를 사용하여 서로 통신할 수 있습니다. Pause 컨테이너가 모든 컨테이너들이 공유하는 네트워크 네임스페이스를 관리하므로, 로컬호스트 주소를 통해 컨테이너들이 통신할 수 있습니다.

파드 내 컨테이너에게 부모처럼 net namespace 제공해준다. 파드 내 복수의 컨테이너는 공통으로 pause 컨테이너가 제공한 network namespace를 공유한다. 

모든 파드에 반드시 실행된다.

https://jerryljh.tistory.com/57

Pause 컨테이너 정리