Private IP와 Public IP

  • private IP: 로컬 네트워크 내에서만 유효하고 외부 인터넷에서 직접 접근할 수 없다.(NAT를 통해 public IP로 전환해야함)
  • public IP: 인터넷 상에서 고유하게 식별되며, 외부에서 직접 접근할 수 있다.

⭐️ 쿠버네티스 같은 환경에서는 내부 네트워크에서 private IP를 사용하지만, 외부 네트워크로의 접근은 public IP를 통해 이루어진다!!!

Container Network Namespace

Network Namespace를 통해서 고립성을 보장한다. 서로 다른 네임스페이스의 파드들은 소통하기 위해서 bridge를 사용한다.

Kubernetes Network Basic

<aside> 📢

핵심만 말하면 쿠버네티스는 NAT를 쓰지 않음!!!

</aside>

  1. 모든 컨테이너는 NAT 없이도 서로 소통할 수 있다.
    • 즉, 각 컨테이너가 고유의 IP 주소를 가지며, 네트워크 내부에서 그 주소로 직접 통신할 수 있다!
  2. 모든 노드는 NAT 없이 모든 컨테이너와 통신할 수 있다.
    • 노드와 컨테이너의 통신이 NAT 없이 가능하다.
    • 예를 들면, 노드에 있는 어떤 pod에서 다른 노드에 있는 pod로도 직접 소통할 수있따. 모든 노드는 서로 평등한 네트워크 접근성을 가진다!
  3. 컨테이너가 스스로 인식하는 IP는 다른 컨테이너나 노드가 보는 것과 동일해야 한다.
    • pod와 컨테이너는 스스로를 인식할 때 고유의 IP 주소를 가지게 된다.
  4. 서비스 클러스터 IP 범위는 노드에 할당된 IP 범위와 중복되지 않아야 한다.

자, 클러스터의 IP주소를좀 알아보자.

클러스터에서 Pod, Node, Service 각각은 고유한 IP 주소를 할당받아서 연결된다.

Node는 private IP를 통해 네트워크 간 통신을 담당하고, Pod는 해당 노드 내에서 고유 IP를 가져 통신한다. Service는 클러스터 내에서 여러 파드를 묶어 로드 밸런싱하고, 클러스터 외부와 통신할때 Cluster IP를 사용한다.

Kubernetes의 IP 주소

service, pod, container, node는 IP 주소와 port를 이용해서 통신한다.

Node IP

말그대로 클러스터의 각 노드에 할당된 IP주소를 의미한다. 노드는 pod를 호스팅하는 VM, server 등등,,이기 때문에 여튼 고유한 IP 주소가 필요하다. 그래서 private IP가 할당된다.

Pod IP

Pod IP는 Pod에 할당된 IP 주소이다. pod는 쿠버네티스에서 가장 작은 네트워크 단위이고, 내부에 하나 이상의 컨테이너가 있을 수 있다. 다만 Pod IP는 pod가 생성될때마다 새로운 IP를 할당받고, pod가 재시작되거나 삭제될 경우 해당 IP는 사라지게 된다. 고정되지 않고 임시적이다!! CNI 플러그인이 이 IP 주소 할당을 관리한다.

Cluster IP

서비스에 할당되는 IP주소 이다. 서비스는 클러스터 내에서 고유한 ClusterIP를 가짐. 이 IP 주소는 서비스가 삭제될 때까지 고정돼 있다.


Kubernetes에서 Service

Service는 쿠버네티스에서 Pod를 묶어 외부 트래픽이 접근할 수 있도록하는 추상화된 리소스! 라고 할 수 있다. Pod의 집합을 묶어서 **서비스엔드포인트(ClusterIP)**로 제공하고, 어떤 정책에 따라 그 서비스에 접근할 수 있게 도와준다. 그리고 이때 LabelSelector를 이용해서 어느 pod들이 서비스에 포함될지 결정한다.

그렇다면 서비스의 유형에 어떤 것들이 있는지 살펴보자.

1. Cluster IP (private)

default값이고, 클러스터 내부에서만 접근 가능하다. private하므로 외부에서는 이용할 수 없다!

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  type: ClusterIP
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

2. NodePort (private + public)

클러스터 외부에서 Node의 IP와 Port를 통해 접근할 수 있다. 외부 트래픽을 받아서 port에 맞는 pod로 전달하는 방식이다.

예시를 들어보자면, 형남 105호가 public주소이고, 그 안에 들어있는 학생들이 private이다. 우리는 public 주소의 포트 넘버를 알려주어야하고, NAT가 포트넘버를 보고 연결해 주는 역할을 한다.

NodePort 방식은 클러스터 외부에서 클러스터 내부로 접근하게 해주지만, 그 과정에서 NAT가 사용되어 공인 IP를 내부 Pod의 Private IP로 매핑해주는 역할을 하게 된다.

apiVersion: v1
kind: Service
metadata:
  name: my-nodeport-service
spec:
  type: NodePort
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
      nodePort: 30007

  • 쿠버네티스는 이때 특정 범위의 포트 번호(기본적으로 30000~32767)를 사용해, 클러스터 내의 모든 노드에서 해당 포트를 열어둬.
  • 클러스터 외부에서 접근할 때는 [NodeIP]:[NodePort] 형식으로 접근하게 되는데, 이렇게 하면 클러스터 외부 트래픽이 해당 포트를 통해 Pod로 전달돼.
  • NodePort는 간단하지만, 여러 노드에 동일한 포트가 열리므로 큰 규모의 트래픽 관리에는 적합하지 않을 수 있어.
  • 예시: 클러스터 외부에서 특정 애플리케이션에 접근해야 하는 경우 사용돼.

3. LoadBalancer

클라우드 환경에서 많이 쓰이는 방식으로 외부에 고정된 public IP 주소를 할당한다. 그리고 로드밸런서를 통해 여러 pod로 트래픽을 분산시키는 방법이다. NordPort와 ClusterIP 기능을 포함한다.

쉽게 말해서 접속 전문 박스가 있고, 그 박스까지만 잘 찾아오면 그 박스가 알아서 해준다?

4. ExternalName

DNS 이름을 외부 서비스로 매핑해준다. pod가 아닌 외부 서비스로 연결하고 싶을 때 사용하는 방식이다.

<aside> 📢

시험 nginx 서비스를 뜯어보면 똑같은 기능을 하는 pod 2개(고정주소,가변주소)로 고정되어 있다. 만약 한 서비스에 똑같은 기능 pod가 3개라면?????

pod가 3개 있을때, 서비스는 각각의 파드에 대해서 엔드포인트를 관리한다. pod IP는 가변적이잖아? 만약 pod가 죽거나 생성되면 IP가 바뀌지? 그럴떄 서비스는 해당 pod의 상태를 추적해서, 외부에서 온 요청을 적절한 살아있는 Pod로 보내준다. endpoints는 이러한 pod 상태를 관리하는 역할을 하고, 서비스가 항상 안정적으로 제공될 수 있도록 돕는다. 그리고 로드밸런싱을 통해 적절히 부하가 오지 않게 유지한다.

endpoints는 쿠버네티스에서 서비스와 연결된 pod들의 ip주소와 포트 정보를 추적하고 관리하는 리소스이다!

엔드포인트와 kubelet, kube-proxy의 차이점:

엔드포인트(Endpoints):

서비스와 연결된 Pod들의 IP와 포트 정보를 관리합니다.

Pod의 상태나 생명주기를 직접 관리하지는 않습니다. 대신, Pod가 추가되거나 제거될 때 이 정보가 업데이트됩니다.

kubelet:

Pod의 상태를 관리하고, Pod의 생성, 실행, 종료를 담당합니다.

• Pod가 정상적으로 실행되고 있는지 모니터링하며, 상태가 나빠지면 이를 API 서버에 보고합니다.

kube-proxy: (mapping table)

네트워크 트래픽을 관리하여, 서비스에서 Pod로 또는 Pod 간의 트래픽을 엔드포인트 정보를 기반으로 라우팅합니다.

엔드포인트 정보를 사용하여 적절한 Pod로 트래픽을 전달합니다.

</aside>

Service, Label, Label Selector

  • Label은 Kubernetes 오브젝트(Pod, Service, Node 등)에 붙일 수 있는 키-값 쌍이야. 이 라벨을 통해 오브젝트들을 분류하거나 그룹화할 수 있어. 예를 들어, "app=nginx"라는 라벨을 Pod에 붙일 수 있지.
  • Label SelectorServiceReplicaSet 등에서 특정 라벨이 붙은 오브젝트를 선택할 때 사용돼. 예를 들어, "app=nginx"라는 라벨이 붙은 모든 Pod를 선택해서 Service가 연결하도록 설정할 수 있어.

NortPort Service를 위한 yaml 파일의 내용 예시

1. NodePort 서비스 개념:

NodePortKubernetes 서비스 유형 중 하나로, 클러스터 외부에서 **Node의 IP와 지정된 포트(NodePort)**를 통해 클러스터 내의 Service로 접근할 수 있게 해주는 방식입니다.

2. 트래픽 흐름:

  1. 외부 트래픽 (1번 - NodePort):

• 외부 사용자가 192.168.1.1:31000으로 접속을 시도합니다. 이 31000번 포트NodePort입니다.

• 이 포트를 통해 클러스터 내부로 트래픽이 전달됩니다.

  1. Service에서 내부 Pod로의 트래픽 전달 (2번 - Port):

Service가 이 트래픽을 받아서 10.180.0.15:80으로 내부 트래픽을 전달합니다. 이 80번 포트Service가 외부 트래픽을 받아들이는 포트입니다.

• Service는 해당 트래픽을 적절한 Pod로 보내기 위해 Pod의 IPTargetPort를 사용합니다.

  1. Pod로 트래픽 전달 (3번 - TargetPort):

• Service는 내부 PodTargetPort 80을 향해 트래픽을 전달합니다. 10.210.0.4는 실제 nginx-app Pod의 IP입니다.

• Pod 내에서 애플리케이션이 80번 포트로 실행되고 있으며, 이를 통해 외부 트래픽을 처리합니다.

3. YAML 파일 설명:

Service (왼쪽):

Servicemy-service라는 이름으로 생성되었으며, NodePort 타입입니다.

Selectorapp: nginx-app이라는 라벨을 가진 Pod를 선택하고, nodePort 31000을 통해 외부 트래픽을 수신합니다.

• 내부적으로는 port 80targetPort 80으로 Pod에 연결됩니다.

Deployment (오른쪽):

Deploymentnginx-app이라는 Pod를 생성하는 역할을 합니다.

replicas: 1로 설정되어 하나의 Pod를 생성하며, 해당 Podapp: nginx-app 라벨을 가지고 있습니다.

• 이 라벨을 통해 Service가 해당 Pod로 트래픽을 라우팅할 수 있게 됩니다.

nginx-container80번 포트에서 애플리케이션을 실행하고 있습니다.

요약:

• 외부 트래픽이 **NodePort(31000)**를 통해 Service로 전달되고, Service는 내부 **Pod(nginx-app)**로 트래픽을 전달하여 애플리케이션을 실행하고 처리합니다.

apiVersion: apps/v1
kind: Deployment
metadata: 
  name: apache-deployment
spec:
  selector: 
    matchLabels:
      app: webserver
  replicas: 1
  template:
    metadata: 
      labels: 
        app: webserver
    spec: 
      containers:
      - name: php-apache
        image: k8s.gcr.io/hpa-example
        ports:
        - containerPort: 80
apiVersion: v1
kind: Service
metadata:
  name: webserver
  labels:
    app: webserver
spec: 
  type: NodePort
  ports: 
  - port: 8080

Private IP와 Public IP

  • private IP: 로컬 네트워크 내에서만 유효하고 외부 인터넷에서 직접 접근할 수 없다.(NAT를 통해 public IP로 전환해야함)
  • public IP: 인터넷 상에서 고유하게 식별되며, 외부에서 직접 접근할 수 있다.

⭐️ 쿠버네티스 같은 환경에서는 내부 네트워크에서 private IP를 사용하지만, 외부 네트워크로의 접근은 public IP를 통해 이루어진다!!!

Container Network Namespace

Network Namespace를 통해서 고립성을 보장한다. 서로 다른 네임스페이스의 파드들은 소통하기 위해서 bridge를 사용한다.

Kubernetes Network Basic

<aside> 📢

핵심만 말하면 쿠버네티스는 NAT를 쓰지 않음!!!

</aside>

  1. 모든 컨테이너는 NAT 없이도 서로 소통할 수 있다.
    • 즉, 각 컨테이너가 고유의 IP 주소를 가지며, 네트워크 내부에서 그 주소로 직접 통신할 수 있다!
  2. 모든 노드는 NAT 없이 모든 컨테이너와 통신할 수 있다.
    • 노드와 컨테이너의 통신이 NAT 없이 가능하다.
    • 예를 들면, 노드에 있는 어떤 pod에서 다른 노드에 있는 pod로도 직접 소통할 수있따. 모든 노드는 서로 평등한 네트워크 접근성을 가진다!
  3. 컨테이너가 스스로 인식하는 IP는 다른 컨테이너나 노드가 보는 것과 동일해야 한다.
    • pod와 컨테이너는 스스로를 인식할 때 고유의 IP 주소를 가지게 된다.
  4. 서비스 클러스터 IP 범위는 노드에 할당된 IP 범위와 중복되지 않아야 한다.

자, 클러스터의 IP주소를좀 알아보자.

클러스터에서 Pod, Node, Service 각각은 고유한 IP 주소를 할당받아서 연결된다.

Node는 private IP를 통해 네트워크 간 통신을 담당하고, Pod는 해당 노드 내에서 고유 IP를 가져 통신한다. Service는 클러스터 내에서 여러 파드를 묶어 로드 밸런싱하고, 클러스터 외부와 통신할때 Cluster IP를 사용한다.

Kubernetes의 IP 주소

service, pod, container, node는 IP 주소와 port를 이용해서 통신한다.

Node IP

말그대로 클러스터의 각 노드에 할당된 IP주소를 의미한다. 노드는 pod를 호스팅하는 VM, server 등등,,이기 때문에 여튼 고유한 IP 주소가 필요하다. 그래서 private IP가 할당된다.

Pod IP

Pod IP는 Pod에 할당된 IP 주소이다. pod는 쿠버네티스에서 가장 작은 네트워크 단위이고, 내부에 하나 이상의 컨테이너가 있을 수 있다. 다만 Pod IP는 pod가 생성될때마다 새로운 IP를 할당받고, pod가 재시작되거나 삭제될 경우 해당 IP는 사라지게 된다. 고정되지 않고 임시적이다!! CNI 플러그인이 이 IP 주소 할당을 관리한다.

Cluster IP

서비스에 할당되는 IP주소 이다. 서비스는 클러스터 내에서 고유한 ClusterIP를 가짐. 이 IP 주소는 서비스가 삭제될 때까지 고정돼 있다.


Kubernetes에서 Service

Service는 쿠버네티스에서 Pod를 묶어 외부 트래픽이 접근할 수 있도록하는 추상화된 리소스! 라고 할 수 있다. Pod의 집합을 묶어서 **서비스엔드포인트(ClusterIP)**로 제공하고, 어떤 정책에 따라 그 서비스에 접근할 수 있게 도와준다. 그리고 이때 LabelSelector를 이용해서 어느 pod들이 서비스에 포함될지 결정한다.

그렇다면 서비스의 유형에 어떤 것들이 있는지 살펴보자.

1. Cluster IP (private)

default값이고, 클러스터 내부에서만 접근 가능하다. private하므로 외부에서는 이용할 수 없다!

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  type: ClusterIP
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

2. NodePort (private + public)

클러스터 외부에서 Node의 IP와 Port를 통해 접근할 수 있다. 외부 트래픽을 받아서 port에 맞는 pod로 전달하는 방식이다.

예시를 들어보자면, 형남 105호가 public주소이고, 그 안에 들어있는 학생들이 private이다. 우리는 public 주소의 포트 넘버를 알려주어야하고, NAT가 포트넘버를 보고 연결해 주는 역할을 한다.

NodePort 방식은 클러스터 외부에서 클러스터 내부로 접근하게 해주지만, 그 과정에서 NAT가 사용되어 공인 IP를 내부 Pod의 Private IP로 매핑해주는 역할을 하게 된다.

apiVersion: v1
kind: Service
metadata:
  name: my-nodeport-service
spec:
  type: NodePort
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
      nodePort: 30007

  • 쿠버네티스는 이때 특정 범위의 포트 번호(기본적으로 30000~32767)를 사용해, 클러스터 내의 모든 노드에서 해당 포트를 열어둬.
  • 클러스터 외부에서 접근할 때는 [NodeIP]:[NodePort] 형식으로 접근하게 되는데, 이렇게 하면 클러스터 외부 트래픽이 해당 포트를 통해 Pod로 전달돼.
  • NodePort는 간단하지만, 여러 노드에 동일한 포트가 열리므로 큰 규모의 트래픽 관리에는 적합하지 않을 수 있어.
  • 예시: 클러스터 외부에서 특정 애플리케이션에 접근해야 하는 경우 사용돼.

3. LoadBalancer

클라우드 환경에서 많이 쓰이는 방식으로 외부에 고정된 public IP 주소를 할당한다. 그리고 로드밸런서를 통해 여러 pod로 트래픽을 분산시키는 방법이다. NordPort와 ClusterIP 기능을 포함한다.

쉽게 말해서 접속 전문 박스가 있고, 그 박스까지만 잘 찾아오면 그 박스가 알아서 해준다?

4. ExternalName

DNS 이름을 외부 서비스로 매핑해준다. pod가 아닌 외부 서비스로 연결하고 싶을 때 사용하는 방식이다.

<aside> 📢

시험 nginx 서비스를 뜯어보면 똑같은 기능을 하는 pod 2개(고정주소,가변주소)로 고정되어 있다. 만약 한 서비스에 똑같은 기능 pod가 3개라면?????

pod가 3개 있을때, 서비스는 각각의 파드에 대해서 엔드포인트를 관리한다. pod IP는 가변적이잖아? 만약 pod가 죽거나 생성되면 IP가 바뀌지? 그럴떄 서비스는 해당 pod의 상태를 추적해서, 외부에서 온 요청을 적절한 살아있는 Pod로 보내준다. endpoints는 이러한 pod 상태를 관리하는 역할을 하고, 서비스가 항상 안정적으로 제공될 수 있도록 돕는다. 그리고 로드밸런싱을 통해 적절히 부하가 오지 않게 유지한다.

endpoints는 쿠버네티스에서 서비스와 연결된 pod들의 ip주소와 포트 정보를 추적하고 관리하는 리소스이다!

엔드포인트와 kubelet, kube-proxy의 차이점:

엔드포인트(Endpoints):

서비스와 연결된 Pod들의 IP와 포트 정보를 관리합니다.

Pod의 상태나 생명주기를 직접 관리하지는 않습니다. 대신, Pod가 추가되거나 제거될 때 이 정보가 업데이트됩니다.

kubelet:

Pod의 상태를 관리하고, Pod의 생성, 실행, 종료를 담당합니다.

• Pod가 정상적으로 실행되고 있는지 모니터링하며, 상태가 나빠지면 이를 API 서버에 보고합니다.

kube-proxy: (mapping table)

네트워크 트래픽을 관리하여, 서비스에서 Pod로 또는 Pod 간의 트래픽을 엔드포인트 정보를 기반으로 라우팅합니다.

엔드포인트 정보를 사용하여 적절한 Pod로 트래픽을 전달합니다.

</aside>

Service, Label, Label Selector

  • Label은 Kubernetes 오브젝트(Pod, Service, Node 등)에 붙일 수 있는 키-값 쌍이야. 이 라벨을 통해 오브젝트들을 분류하거나 그룹화할 수 있어. 예를 들어, "app=nginx"라는 라벨을 Pod에 붙일 수 있지.
  • Label SelectorServiceReplicaSet 등에서 특정 라벨이 붙은 오브젝트를 선택할 때 사용돼. 예를 들어, "app=nginx"라는 라벨이 붙은 모든 Pod를 선택해서 Service가 연결하도록 설정할 수 있어.

NortPort Service를 위한 yaml 파일의 내용 예시

1. NodePort 서비스 개념:

NodePortKubernetes 서비스 유형 중 하나로, 클러스터 외부에서 **Node의 IP와 지정된 포트(NodePort)**를 통해 클러스터 내의 Service로 접근할 수 있게 해주는 방식입니다.

2. 트래픽 흐름:

  1. 외부 트래픽 (1번 - NodePort):

• 외부 사용자가 192.168.1.1:31000으로 접속을 시도합니다. 이 31000번 포트NodePort입니다.

• 이 포트를 통해 클러스터 내부로 트래픽이 전달됩니다.

  1. Service에서 내부 Pod로의 트래픽 전달 (2번 - Port):

Service가 이 트래픽을 받아서 10.180.0.15:80으로 내부 트래픽을 전달합니다. 이 80번 포트Service가 외부 트래픽을 받아들이는 포트입니다.

• Service는 해당 트래픽을 적절한 Pod로 보내기 위해 Pod의 IPTargetPort를 사용합니다.

  1. Pod로 트래픽 전달 (3번 - TargetPort):

• Service는 내부 PodTargetPort 80을 향해 트래픽을 전달합니다. 10.210.0.4는 실제 nginx-app Pod의 IP입니다.

• Pod 내에서 애플리케이션이 80번 포트로 실행되고 있으며, 이를 통해 외부 트래픽을 처리합니다.

3. YAML 파일 설명:

Service (왼쪽):

Servicemy-service라는 이름으로 생성되었으며, NodePort 타입입니다.

Selectorapp: nginx-app이라는 라벨을 가진 Pod를 선택하고, nodePort 31000을 통해 외부 트래픽을 수신합니다.

• 내부적으로는 port 80targetPort 80으로 Pod에 연결됩니다.

Deployment (오른쪽):

Deploymentnginx-app이라는 Pod를 생성하는 역할을 합니다.

replicas: 1로 설정되어 하나의 Pod를 생성하며, 해당 Podapp: nginx-app 라벨을 가지고 있습니다.

• 이 라벨을 통해 Service가 해당 Pod로 트래픽을 라우팅할 수 있게 됩니다.

nginx-container80번 포트에서 애플리케이션을 실행하고 있습니다.

요약:

• 외부 트래픽이 **NodePort(31000)**를 통해 Service로 전달되고, Service는 내부 **Pod(nginx-app)**로 트래픽을 전달하여 애플리케이션을 실행하고 처리합니다.

apiVersion: apps/v1
kind: Deployment
metadata: 
  name: apache-deployment
spec:
  selector: 
    matchLabels:
      app: webserver
  replicas: 1
  template:
    metadata: 
      labels: 
        app: webserver
    spec: 
      containers:
      - name: php-apache
        image: k8s.gcr.io/hpa-example
        ports:
        - containerPort: 80
apiVersion: v1
kind: Service
metadata:
  name: webserver
  labels:
    app: webserver
spec: 
  type: NodePort
  ports: 
  - port: 8080

Private IP와 Public IP

  • private IP: 로컬 네트워크 내에서만 유효하고 외부 인터넷에서 직접 접근할 수 없다.(NAT를 통해 public IP로 전환해야함)
  • public IP: 인터넷 상에서 고유하게 식별되며, 외부에서 직접 접근할 수 있다.

⭐️ 쿠버네티스 같은 환경에서는 내부 네트워크에서 private IP를 사용하지만, 외부 네트워크로의 접근은 public IP를 통해 이루어진다!!!

Container Network Namespace

Network Namespace를 통해서 고립성을 보장한다. 서로 다른 네임스페이스의 파드들은 소통하기 위해서 bridge를 사용한다.

Kubernetes Network Basic

<aside> 📢

핵심만 말하면 쿠버네티스는 NAT를 쓰지 않음!!!

</aside>

  1. 모든 컨테이너는 NAT 없이도 서로 소통할 수 있다.
    • 즉, 각 컨테이너가 고유의 IP 주소를 가지며, 네트워크 내부에서 그 주소로 직접 통신할 수 있다!
  2. 모든 노드는 NAT 없이 모든 컨테이너와 통신할 수 있다.
    • 노드와 컨테이너의 통신이 NAT 없이 가능하다.
    • 예를 들면, 노드에 있는 어떤 pod에서 다른 노드에 있는 pod로도 직접 소통할 수있따. 모든 노드는 서로 평등한 네트워크 접근성을 가진다!
  3. 컨테이너가 스스로 인식하는 IP는 다른 컨테이너나 노드가 보는 것과 동일해야 한다.
    • pod와 컨테이너는 스스로를 인식할 때 고유의 IP 주소를 가지게 된다.
  4. 서비스 클러스터 IP 범위는 노드에 할당된 IP 범위와 중복되지 않아야 한다.

자, 클러스터의 IP주소를좀 알아보자.

클러스터에서 Pod, Node, Service 각각은 고유한 IP 주소를 할당받아서 연결된다.

Node는 private IP를 통해 네트워크 간 통신을 담당하고, Pod는 해당 노드 내에서 고유 IP를 가져 통신한다. Service는 클러스터 내에서 여러 파드를 묶어 로드 밸런싱하고, 클러스터 외부와 통신할때 Cluster IP를 사용한다.

Kubernetes의 IP 주소

service, pod, container, node는 IP 주소와 port를 이용해서 통신한다.

Node IP

말그대로 클러스터의 각 노드에 할당된 IP주소를 의미한다. 노드는 pod를 호스팅하는 VM, server 등등,,이기 때문에 여튼 고유한 IP 주소가 필요하다. 그래서 private IP가 할당된다.

Pod IP

Pod IP는 Pod에 할당된 IP 주소이다. pod는 쿠버네티스에서 가장 작은 네트워크 단위이고, 내부에 하나 이상의 컨테이너가 있을 수 있다. 다만 Pod IP는 pod가 생성될때마다 새로운 IP를 할당받고, pod가 재시작되거나 삭제될 경우 해당 IP는 사라지게 된다. 고정되지 않고 임시적이다!! CNI 플러그인이 이 IP 주소 할당을 관리한다.

Cluster IP

서비스에 할당되는 IP주소 이다. 서비스는 클러스터 내에서 고유한 ClusterIP를 가짐. 이 IP 주소는 서비스가 삭제될 때까지 고정돼 있다.


Kubernetes에서 Service

Service는 쿠버네티스에서 Pod를 묶어 외부 트래픽이 접근할 수 있도록하는 추상화된 리소스! 라고 할 수 있다. Pod의 집합을 묶어서 **서비스엔드포인트(ClusterIP)**로 제공하고, 어떤 정책에 따라 그 서비스에 접근할 수 있게 도와준다. 그리고 이때 LabelSelector를 이용해서 어느 pod들이 서비스에 포함될지 결정한다.

그렇다면 서비스의 유형에 어떤 것들이 있는지 살펴보자.

1. Cluster IP (private)

default값이고, 클러스터 내부에서만 접근 가능하다. private하므로 외부에서는 이용할 수 없다!

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  type: ClusterIP
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

2. NodePort (private + public)

클러스터 외부에서 Node의 IP와 Port를 통해 접근할 수 있다. 외부 트래픽을 받아서 port에 맞는 pod로 전달하는 방식이다.

예시를 들어보자면, 형남 105호가 public주소이고, 그 안에 들어있는 학생들이 private이다. 우리는 public 주소의 포트 넘버를 알려주어야하고, NAT가 포트넘버를 보고 연결해 주는 역할을 한다.

NodePort 방식은 클러스터 외부에서 클러스터 내부로 접근하게 해주지만, 그 과정에서 NAT가 사용되어 공인 IP를 내부 Pod의 Private IP로 매핑해주는 역할을 하게 된다.

apiVersion: v1
kind: Service
metadata:
  name: my-nodeport-service
spec:
  type: NodePort
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
      nodePort: 30007

  • 쿠버네티스는 이때 특정 범위의 포트 번호(기본적으로 30000~32767)를 사용해, 클러스터 내의 모든 노드에서 해당 포트를 열어둬.
  • 클러스터 외부에서 접근할 때는 [NodeIP]:[NodePort] 형식으로 접근하게 되는데, 이렇게 하면 클러스터 외부 트래픽이 해당 포트를 통해 Pod로 전달돼.
  • NodePort는 간단하지만, 여러 노드에 동일한 포트가 열리므로 큰 규모의 트래픽 관리에는 적합하지 않을 수 있어.
  • 예시: 클러스터 외부에서 특정 애플리케이션에 접근해야 하는 경우 사용돼.

3. LoadBalancer

클라우드 환경에서 많이 쓰이는 방식으로 외부에 고정된 public IP 주소를 할당한다. 그리고 로드밸런서를 통해 여러 pod로 트래픽을 분산시키는 방법이다. NordPort와 ClusterIP 기능을 포함한다.

쉽게 말해서 접속 전문 박스가 있고, 그 박스까지만 잘 찾아오면 그 박스가 알아서 해준다?

4. ExternalName

DNS 이름을 외부 서비스로 매핑해준다. pod가 아닌 외부 서비스로 연결하고 싶을 때 사용하는 방식이다.

<aside> 📢

시험 nginx 서비스를 뜯어보면 똑같은 기능을 하는 pod 2개(고정주소,가변주소)로 고정되어 있다. 만약 한 서비스에 똑같은 기능 pod가 3개라면?????

pod가 3개 있을때, 서비스는 각각의 파드에 대해서 엔드포인트를 관리한다. pod IP는 가변적이잖아? 만약 pod가 죽거나 생성되면 IP가 바뀌지? 그럴떄 서비스는 해당 pod의 상태를 추적해서, 외부에서 온 요청을 적절한 살아있는 Pod로 보내준다. endpoints는 이러한 pod 상태를 관리하는 역할을 하고, 서비스가 항상 안정적으로 제공될 수 있도록 돕는다. 그리고 로드밸런싱을 통해 적절히 부하가 오지 않게 유지한다.

endpoints는 쿠버네티스에서 서비스와 연결된 pod들의 ip주소와 포트 정보를 추적하고 관리하는 리소스이다!

엔드포인트와 kubelet, kube-proxy의 차이점:

엔드포인트(Endpoints):

서비스와 연결된 Pod들의 IP와 포트 정보를 관리합니다.

Pod의 상태나 생명주기를 직접 관리하지는 않습니다. 대신, Pod가 추가되거나 제거될 때 이 정보가 업데이트됩니다.

kubelet:

Pod의 상태를 관리하고, Pod의 생성, 실행, 종료를 담당합니다.

• Pod가 정상적으로 실행되고 있는지 모니터링하며, 상태가 나빠지면 이를 API 서버에 보고합니다.

kube-proxy: (mapping table)

네트워크 트래픽을 관리하여, 서비스에서 Pod로 또는 Pod 간의 트래픽을 엔드포인트 정보를 기반으로 라우팅합니다.

엔드포인트 정보를 사용하여 적절한 Pod로 트래픽을 전달합니다.

</aside>

Service, Label, Label Selector

  • Label은 Kubernetes 오브젝트(Pod, Service, Node 등)에 붙일 수 있는 키-값 쌍이야. 이 라벨을 통해 오브젝트들을 분류하거나 그룹화할 수 있어. 예를 들어, "app=nginx"라는 라벨을 Pod에 붙일 수 있지.
  • Label SelectorServiceReplicaSet 등에서 특정 라벨이 붙은 오브젝트를 선택할 때 사용돼. 예를 들어, "app=nginx"라는 라벨이 붙은 모든 Pod를 선택해서 Service가 연결하도록 설정할 수 있어.

NortPort Service를 위한 yaml 파일의 내용 예시

1. NodePort 서비스 개념:

NodePortKubernetes 서비스 유형 중 하나로, 클러스터 외부에서 **Node의 IP와 지정된 포트(NodePort)**를 통해 클러스터 내의 Service로 접근할 수 있게 해주는 방식입니다.

2. 트래픽 흐름:

  1. 외부 트래픽 (1번 - NodePort):

• 외부 사용자가 192.168.1.1:31000으로 접속을 시도합니다. 이 31000번 포트NodePort입니다.

• 이 포트를 통해 클러스터 내부로 트래픽이 전달됩니다.

  1. Service에서 내부 Pod로의 트래픽 전달 (2번 - Port):

Service가 이 트래픽을 받아서 10.180.0.15:80으로 내부 트래픽을 전달합니다. 이 80번 포트Service가 외부 트래픽을 받아들이는 포트입니다.

• Service는 해당 트래픽을 적절한 Pod로 보내기 위해 Pod의 IPTargetPort를 사용합니다.

  1. Pod로 트래픽 전달 (3번 - TargetPort):

• Service는 내부 PodTargetPort 80을 향해 트래픽을 전달합니다. 10.210.0.4는 실제 nginx-app Pod의 IP입니다.

• Pod 내에서 애플리케이션이 80번 포트로 실행되고 있으며, 이를 통해 외부 트래픽을 처리합니다.

3. YAML 파일 설명:

Service (왼쪽):

Servicemy-service라는 이름으로 생성되었으며, NodePort 타입입니다.

Selectorapp: nginx-app이라는 라벨을 가진 Pod를 선택하고, nodePort 31000을 통해 외부 트래픽을 수신합니다.

• 내부적으로는 port 80targetPort 80으로 Pod에 연결됩니다.

Deployment (오른쪽):

Deploymentnginx-app이라는 Pod를 생성하는 역할을 합니다.

replicas: 1로 설정되어 하나의 Pod를 생성하며, 해당 Podapp: nginx-app 라벨을 가지고 있습니다.

• 이 라벨을 통해 Service가 해당 Pod로 트래픽을 라우팅할 수 있게 됩니다.

nginx-container80번 포트에서 애플리케이션을 실행하고 있습니다.

요약:

• 외부 트래픽이 **NodePort(31000)**를 통해 Service로 전달되고, Service는 내부 **Pod(nginx-app)**로 트래픽을 전달하여 애플리케이션을 실행하고 처리합니다.

apiVersion: apps/v1
kind: Deployment
metadata: 
  name: apache-deployment
spec:
  selector: 
    matchLabels:
      app: webserver
  replicas: 1
  template:
    metadata: 
      labels: 
        app: webserver
    spec: 
      containers:
      - name: php-apache
        image: k8s.gcr.io/hpa-example
        ports:
        - containerPort: 80
apiVersion: v1
kind: Service
metadata:
  name: webserver
  labels:
    app: webserver
spec: 
  type: NodePort
  ports: 
  - port: 8080

'Kubernetes' 카테고리의 다른 글

Kubernetes Volumes  (2) 2024.11.13
Kubectl  (0) 2024.11.06
Application Deployment  (4) 2024.11.06
Configuration File (YAML format), Label, Selector  (1) 2024.10.29
Kubernetes Design Principle  (2) 2024.10.29
코코자