Kubernetes를 통한 동일한 포드 컨테이너의 프로세스 간 통신
2967 단어 containerkubernetestraining
1. 소개
제1회에서는, Kubernetes에 있어서의 Pod를 정의하기 시작해, 복수 컨테이너로 구성되는 Pod의 유스 케이스의 소개에 이어, 컨테이너간 통신중에서도 공유 볼륨을 통한 컨테이너간 통신에 대해 설명했습니다. 이번에는 컨테이너 간 통신 중에서도 프로세스 간 통신을 다룹니다.
2. 프로세스 간 통신
포드의 컨테이너는 IPC(IPC:Inter-process communications) 네임스페이스를 공유합니다. 즉 시스템 V 세마포어나 POSIX 공유 라이브러리 등의 표준 프로세스간 통신을 이용합니다.
다음 예제에서는 먼저 동일한 포드에 두 개의 컨테이너를 정의합니다. 두 컨테이너 모두 동일한 Docker 이미지를 사용합니다. 첫 번째 컨테이너를 제작자로 설정합니다. 표준 리눅스 메세지 큐를 작성하고 임의의 메세지를 일정수 기입한 후에 메세지 종료를 의미하는 종료 메세지를 기입합니다. 두 번째 컨테이너는 소비자입니다. 제작자가 만든 메시지 대기열에 액세스하고 대기열의 메시지를 읽고 종료 메시지를 받을 때까지 메시지를 로드합니다. 다시 시작 정책을 Never로 설정하므로 두 컨테이너가 모두 종료되면 포드도 종료됩니다. 다음 정의 파일에서 두 개의 컨테이너를 단일 포드에 만듭니다.
apiVersion: v1
kind: Pod
metadata:
name: mc2
spec:
containers:
- name: producer
image: allingeek/ch6_ipc
command: ["./ipc", "-producer"]
- name: consumer
image: allingeek/ch6_ipc
command: ["./ipc", "-consumer"]
restartPolicy: Never
위의 동작을 확인하기 위해 "kubectl create"명령을 사용하여 포드를 만든 다음 아래 명령을 사용하여 포드의 상태를 모니터링합니다.
$ kubectl get pods --show-all -w
NAME READY STATUS RESTARTS AGE
mc2 0/2 Pending 0 0s
mc2 0/2 ContainerCreating 0 0s
mc2 0/2 Completed 0 29
각 컨테이너의 로그를 검토하고 첫 번째 컨테이너인 제작자는 두 번째 컨테이너 소비자가 종료를 포함한 모든 메시지를 받았는지 확인합니다.
$ kubectl logs mc2 -c producer
...
Produced: f4
Produced: 1d
Produced: 9e
Produced: 27
$ kubectl logs mc2 -c consumer
...
Consumed: f4
Consumed: 1d
Consumed: 9e
Consumed: 27
Consumed: done
포드 내에서 컨테이너가 시작되는 순서에주의를 기울여야합니다. 이 상태에서 포드의 모든 컨테이너는 동시에 시작됩니다. 즉, 컨테이너의 시작 순서를 결정할 수 없습니다. 위의 IPC 예제에서는 첫 번째 컨테이너 제작자를 시작한 후 메시지를 대기열로 보내기 전에 두 번째 컨테이너가 종료될 수 있습니다. 앞의 예에서는 컨테이너 제작자의 메시지가 이미 대기열에 저장되어 있다고 가정합니다. 따라서 두 번째 컨테이너 시작이 먼저 완료되면 큐에서 메시지를 로드하지 못할 수 있습니다.
Kubernetes Init Containers를 비롯하여 여러 컨테이너의 시작 순서를 제어하는 기능 개발이 현재 진행되고 있습니다. 한편 클라우드 환경에서는 관리가 불가능하다는 것을 전제로 사전에 대응책을 생각해 두는 것이 현명합니다. 메세지 큐가 작성될 때까지, 어플리케이션측에서 대기하도록(듯이) 수정하는 것도 하나의 대응책으로서 생각할 수 있습니다.
3. 마지막으로
이번에는 프로세스 간 통신과 컨테이너 종속성 및 시작 순서에 대한 참고 사항을 설명했습니다. 다음 번에는 컨테이너 간의 네트워크 통신에 대해 설명합니다.
Kubernetets를 실제로 만져보고 Kubernetes의 가능성을 탐구하고 싶은 분은 꼭 Mirantis 교육에 참가하십시오.
【참고자료】
Pavel Chekin (2017), “Multi-container pods and container communication in Kubernetes,” Mirantis Open Cloud Digest, htps //w w. 미란치 s. 코 m / b ぉ g / 무 l 치 - 안녕 r-po ds - an d - 안녕 r , Mirantis Inc.
Reference
이 문제에 관하여(Kubernetes를 통한 동일한 포드 컨테이너의 프로세스 간 통신), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다
https://qiita.com/mamorita/items/15437a1dbcc00919fa4e
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념
(Collection and Share based on the CC Protocol.)
포드의 컨테이너는 IPC(IPC:Inter-process communications) 네임스페이스를 공유합니다. 즉 시스템 V 세마포어나 POSIX 공유 라이브러리 등의 표준 프로세스간 통신을 이용합니다.
다음 예제에서는 먼저 동일한 포드에 두 개의 컨테이너를 정의합니다. 두 컨테이너 모두 동일한 Docker 이미지를 사용합니다. 첫 번째 컨테이너를 제작자로 설정합니다. 표준 리눅스 메세지 큐를 작성하고 임의의 메세지를 일정수 기입한 후에 메세지 종료를 의미하는 종료 메세지를 기입합니다. 두 번째 컨테이너는 소비자입니다. 제작자가 만든 메시지 대기열에 액세스하고 대기열의 메시지를 읽고 종료 메시지를 받을 때까지 메시지를 로드합니다. 다시 시작 정책을 Never로 설정하므로 두 컨테이너가 모두 종료되면 포드도 종료됩니다. 다음 정의 파일에서 두 개의 컨테이너를 단일 포드에 만듭니다.
apiVersion: v1
kind: Pod
metadata:
name: mc2
spec:
containers:
- name: producer
image: allingeek/ch6_ipc
command: ["./ipc", "-producer"]
- name: consumer
image: allingeek/ch6_ipc
command: ["./ipc", "-consumer"]
restartPolicy: Never
위의 동작을 확인하기 위해 "kubectl create"명령을 사용하여 포드를 만든 다음 아래 명령을 사용하여 포드의 상태를 모니터링합니다.
$ kubectl get pods --show-all -w
NAME READY STATUS RESTARTS AGE
mc2 0/2 Pending 0 0s
mc2 0/2 ContainerCreating 0 0s
mc2 0/2 Completed 0 29
각 컨테이너의 로그를 검토하고 첫 번째 컨테이너인 제작자는 두 번째 컨테이너 소비자가 종료를 포함한 모든 메시지를 받았는지 확인합니다.
$ kubectl logs mc2 -c producer
...
Produced: f4
Produced: 1d
Produced: 9e
Produced: 27
$ kubectl logs mc2 -c consumer
...
Consumed: f4
Consumed: 1d
Consumed: 9e
Consumed: 27
Consumed: done
포드 내에서 컨테이너가 시작되는 순서에주의를 기울여야합니다. 이 상태에서 포드의 모든 컨테이너는 동시에 시작됩니다. 즉, 컨테이너의 시작 순서를 결정할 수 없습니다. 위의 IPC 예제에서는 첫 번째 컨테이너 제작자를 시작한 후 메시지를 대기열로 보내기 전에 두 번째 컨테이너가 종료될 수 있습니다. 앞의 예에서는 컨테이너 제작자의 메시지가 이미 대기열에 저장되어 있다고 가정합니다. 따라서 두 번째 컨테이너 시작이 먼저 완료되면 큐에서 메시지를 로드하지 못할 수 있습니다.
Kubernetes Init Containers를 비롯하여 여러 컨테이너의 시작 순서를 제어하는 기능 개발이 현재 진행되고 있습니다. 한편 클라우드 환경에서는 관리가 불가능하다는 것을 전제로 사전에 대응책을 생각해 두는 것이 현명합니다. 메세지 큐가 작성될 때까지, 어플리케이션측에서 대기하도록(듯이) 수정하는 것도 하나의 대응책으로서 생각할 수 있습니다.
3. 마지막으로
이번에는 프로세스 간 통신과 컨테이너 종속성 및 시작 순서에 대한 참고 사항을 설명했습니다. 다음 번에는 컨테이너 간의 네트워크 통신에 대해 설명합니다.
Kubernetets를 실제로 만져보고 Kubernetes의 가능성을 탐구하고 싶은 분은 꼭 Mirantis 교육에 참가하십시오.
【참고자료】
Pavel Chekin (2017), “Multi-container pods and container communication in Kubernetes,” Mirantis Open Cloud Digest, htps //w w. 미란치 s. 코 m / b ぉ g / 무 l 치 - 안녕 r-po ds - an d - 안녕 r , Mirantis Inc.
Reference
이 문제에 관하여(Kubernetes를 통한 동일한 포드 컨테이너의 프로세스 간 통신), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다
https://qiita.com/mamorita/items/15437a1dbcc00919fa4e
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념
(Collection and Share based on the CC Protocol.)
Reference
이 문제에 관하여(Kubernetes를 통한 동일한 포드 컨테이너의 프로세스 간 통신), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://qiita.com/mamorita/items/15437a1dbcc00919fa4e텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)