Kubernetse Linux Namespace 분석 : Pod Container 공유자원 리서치

Kubernetes/Kubernetes 이론

Kubernetse Linux Namespace 분석 : Pod Container 공유자원 리서치

이쿠우우 2024. 7. 14. 21:31

Linux Namespace 공유 자원종류

UTS : Hostname

IPC : 프로세스 간 통신

PID : Process ID

NS : File System의 Mount

NET : Network interface, iptables 등 network 리소스

USER : User와 Group ID

CGROUP : 리소스 제한을 위한 control group

k8s Pod Container의 기본 공유자원

IPC, NET, UTS, PID 는 쉐어한다고함.

공유 자원에 대한 테스트 항목

1. Pod 내 NET(Network) 공유 확인

2. Pod 내 NS(File System) 공유 하지 않음에 대한 확인

3 . Pod 내 UTS(Host name) 공유 확인

이후 항목은 추후 추가 예정....

1. Pod 내 NET(Network) 공유 확인

pod 안에 동일한 port 를 open 한 container를 여러개 생성할 시 오류가 발생

1개의 container는 정상 실행되지만,

나머지 container는 이미 사용중인 port 라는 오류와 함께 생성이 안됨.

kubectl logs [pod] -c [container id ] 명령으로 확인.

[Test 에 사용한 yaml파일 예제]

apiVersion: apps/v1
kind: Deployment
metadata:
  name: iksoon-deployment-test
  labels:
    app: iksoon-test-a
spec:
  replicas: 1
  selector:
    matchLabels:
      app: iksoon-pod-testa
  template:
    metadata:
      labels:
        app: iksoon-pod-testa
    spec:
      containers:   # 동일한 nginx Container 3개를 생성
      - name: iksoon-nginx-a # 이름 중복을 피하기 위해 각각 a,b,c 이름으로 생성
        image: nginx
        ports:
        - containerPort: 81 # container 접근 시 port 중복을 피하기 위해 각각 81,82,83 으로 생성
      - name: iksoon-nginx-b
        image: nginx
        ports:
        - containerPort: 82
      - name: iksoon-nginx-c
        image: nginx
        ports:
        - containerPort: 83

[생성 결과]

Pod 내부의 container 3개 중

1개는 정상 동작 되지만 나머지 2개는 동작 시 CrashLoopBackOff 에러 상태로 계속 재시작을 시도함

[에러 원인]

분석에 사용한 명령어 : kubectl logs pod/iksoon-deployment-test-55bc44749b-hdfzm -c iksoon-nginx-b

아래 그림을 보면 80Port 가 이미 사용중이여서 container를 Running 시키지 못하는 것을 알 수 있음

상위 설정에서 각 Container Port를 81, 82, 83 으로 설정했지만

이는 Pod 에서 Container로 접근할 시의 Port를 명시한 것이고

실제 사용되는 Port 는 nginx 이미지 자체에 설정된 80 Port임.

Container A 가 정상적으로 Running 되면서 80 Port를 사용하고

Container B, C도 80Port를 사용해야 하지만 A가 이미 80을 사용하고 있어서 CrashLoopBackOff 상태가 됨

결론

이 결과로 pod내부의 Container들은 Network를 공유하고 있다는것을 확인할 수 있고,

Pod는 Worker Node Host의 namespace 를 할당 받지만 Host 자체의 네트워크 설정에 영향을 준다는것 을 알 수 있음.

즉 Worker Node Host 에서 Pod 내부의 Container Network 설정 탐지가 가능함을 알 수 있음.

2. Pod 내 NS(File System) 공유 하지 않음에 대한 확인

Pod안의 Container는 동일한 NameSpace지만 FS ( File System ) 을 공유하지 않는다는 것을 증명

Pod안에 동일한 이미지의 container를 여러개 실행 시킨 후 ( images 를 centos 로 사용 )

1번 Container 에 접속해서 /temp (모든 container가 동일하게 있는 경로)에 파일을 생성하고

2,3,4.... Container에서 1번에서 생성했던 파일이 안보인다는것을 확인해야함

Test 에 사용한 yaml파일 예제

apiVersion: apps/v1
kind: Deployment
metadata:
  name: iksoon-deployment-test
  labels:
    app: iksoon-test-a
spec:
  replicas: 1
  selector:
    matchLabels:
      app: iksoon-pod-test
  template:
    metadata:
      labels:
        app: iksoon-pod-test
    spec:
      containers:
      - name: iksoon-centos-a
        image: centos:7
        command: [ "/bin/bash", "-c", "--" ]
        args: [ "while true; do sleep 30; done;" ]
      - name: iksoon-centos-b
        image: centos:7
        command: [ "/bin/bash", "-c", "--" ]
        args: [ "while true; do sleep 30; done;" ]
      - name: iksoon-centos-c
        image: centos:7
        command: [ "/bin/bash", "-c", "--" ]
        args: [ "while true; do sleep 30; done;" ]

[생성 결과]

Pod내부에 동일한 이미지의 container 3가 실행 중인 상태.