ref: 시작하세요 도커/쿠버네티스
이번에는 팟과 도커 컨테이너를 비교해보겠습니다.
사실 저도 이 부분 잘 몰라서 (비슷하게 쓰는데 팟이 더 추상적인 거 아닌가..정도로 생각함) 꼼꼼하게 정리해보겠습니다~!!
Pod vs. Container
여러 기능들만 놓고 본다면 pod는 docker run으로 생성한 컨테이너와 크게 다르지 않아 보일 것입니다.
pod은 컨테이너 IP 주소를 가지고 있어서 쿠버네티스 클러스터 내부에서 접근할 수 있고, kubectl exec 명령어로 포드 컨테이너 내부로 들어갈 수도 있으며, kubectl logs 명령어를 통해 로그를 확인할 수도 있기 때문입니다.
그럼 왜 docker container가 아니라 pod라는 새로운 개념을 사용할까요?
쿠버네티스가 pod을 사용하는 이유는 컨테이너 런타임의 인터페이스 기능 등 여러 가지가 있지만, 그 이유 중 하나는 여러 리눅스 네임스페이스(namespace)를 공유하는 여러 컨테이너들을 추상화된 집합으로 사용하기 위해서입니다.
? 얼추 내 생각이랑 비슷한 것 같은 건 내 착각인가?틀린 말은 아니지만, pod의 개념을 이해하기에는 너무 어려우니 예시로 생각해봅시다.
kubectl get pods 명령어로 pod의 목록을 출력했을 때, ready 항목에서 1/1이라는 출력을 볼 수 있음. nginx pod에는 1개의 컨테이너가 정의되어 있으며, 이 컨테이너는 정상적으로 준비됐다는 뜻을 가지고 있음.
실제로 대부분 쿠버의 컨테이너 애플리케이션은 이처럼 1개의 컨테이너로 pod을 구성해 사용한다.
그러나 1/1이라는 항목에서 알 수 있듯이, pod는 반드시 1개의 컨테이너로 구성해야 하는 것은 아니다. ready 항목은 pod의 컨테이너 개수에 따라 2/2도 될 수 있고, 3/3도 될 수 있다!!
그럼 이번엔 nginx pod에 새로운 우분투 컨테이너를 추가해 보자!
이전에 사용한 yaml 파일을 수정해주자!
❗️ 책에서는 curl이 설치된 우분투 이미지를 미리 올려놓고 그걸 땡겨왔으니까
나는 curl을 설치해서 우분투 이미지를 올려서 땡겨오는 예시를 작성해 볼 것임!
Example
1. curl을 설치한 ubuntu image 생성
docker container 뚝딱뚝딱 만들어주기 + curl 설치해주기
++ 추가 : docker가 멈추지 않게 하기 위해서 마지막에
CMD tail -f /dev/null 추가!!
ref: 도커 컨테이너 실행 유지하기
https://growd.tistory.com/81
container 생성된 것 확인
저거 그냥 나와도 되는데 실명이라 모자이크 너무 귀찮ㅇ..
2. 이제 책에 나온 예제대로 이미지 땡겨오기
땡겨오기 말고 예쁜말 쓰고 싶은데 pull..? 예쁜가..? 이게맞아?
tail 추가해서 이미지 이름 째끔 바꼈움..
두개 비교하려구 cp 해서 이렇게 두개의 파일을 만들었음
원래 있던거 지워주고 (안지워주고 pod 이름 다르게 설정해도 될듯)
새로운 pod 띄워준다 (이미지 두개 들어가있는)
역시 오늘도 그냥 넘어가주지 않음.ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
아마 저 cmd 에러인거같은디.. 책에는 command 설정해서 했는디 저거 안줘서 그런듯.. 일단 자야게써
에러 픽싱은 내일 하겠음. 오늘도 한시다 난 망했다~
++++ 에러해결함 ㅜㅜ
그냥 이미지 잘못 만든 것.. 굳이 args로 인자 줬는데 Dockerfile에서 두번 줘서 에러난거였음..
3. 새롭게 추가된 우분투 컨테이너의 내부로 들어가기
kubectl exec을 이용해 새롭게 추가된 우분투 컨테이너의 내부로 들어갈 수 있음.
kubectl exec,kubectl logs등과 같은 명령어를 사용할 때는-c옵션을 사용해 포드의 어떤 컨테이너에 대해 명령어를 수행할지 명시할 수 있음.
배시 셸을 실행하는 예시
kubectl exec -it my-nginx-pod -c ubuntu-sidecar-container bash인데, 근데 이제 위에꺼 말구
kubectl exec [pod] -- [command]로 쓰랍니다.
🙄 다음 버전에서 명령어가 바뀔 거라고 합니다.
여튼,
ubuntu-sidecar-container 컨테이너 내부에서 로컬호스트로 HTTP 요청을 전송하면 Nginx 서버의 응답이 도착하는 것을 확인할 수 있음.
사이드카 컨테이너(sidecar container)란?
Nginx 컨테이너는 그 자체로 완전한 애플리케이션임. 따라서 하나의 pod에 두개의 nginx 컨테이너가 들어가는 것은 바람직하지 않다.
그런데 이외 부가적인 기능을 필요로 한다면, 예를 들어 nginx의 설정 파일의 변경사항을 갱신해주는 설정 리로더(reloader) 프로세스나 로그를 수집해주는 프로세스는 nginx와 함께 실행되어야 함.
이런 경우 포드의 주 컨테이너를 nginx로 하되, 기능 확장을 위한 추가 컨테이너를 함께 포드에 포함시킬 수 있음.
이렇게 pod에 정의된 부가적인 컨테이너를 사이드가 컨테이너라고 부른다.
사이드카 컨테이너는 포드 내의 다른 컨테이너와 네트워크 환경 등을 공유한다.
때문에 포드에 포함된 컨테이너들은 모두 같은 워커 노드에서 함께 실행된다.
이러한 구조 및 원리에 따라 포드에 정의된 여러 개의 컨테이너는 하나의 완전한 애플리케이션으로서 동작하게 되며, 이것이 도커 컨테이너와 포드의 차이점이다.
