1. Project 환경 구성
프로젝트 생성
- 새 프로젝트를 생성하자. 이름은 자신의 이름 이니셜을 이용해 위와 같이 한다
Kubernetes API 설정
- API 및 서비스에 들어와서 사용 설정에 들어가자
- Kubernete 를 검색해서 Engine API 에 들어가자
- 사용 버튼을 눌러주자
- 사용 요청이 완료되면, 위와 같은 창으로 넘어가진다
Kubernetes Cluster 만들기
- Menu 에서 Kubernetes Engine 에 들어가서 만들기를 눌러주자
- Standard 로 구성을 눌러주자
- default-pool 의 Node 설정으로 들어와서 Docker 가 설치된 Ubuntu 를 선택해주자
- 위와 같이 Node 설정을 선택해주자
- 클러스터 기본사항으로 들어가서 이름과 영역을 지정해주자
- 마지막으로 default-pool 에서 배포할 worker node 수를 확인하고 만들기를 눌러서 Cluster 를 생성하자. 제어 영역은 worker node 의 버전과 동일하게 설정된다
2. Kubernetes Cluster 연결
클러스터에 연결
- 사용할 클러스터를 연결해주자
- 위 명령어를 복사해주자
- Cloud Shell 에 명령어를 붙여넣어 연결해주자
- 잘 연결됬는지 Node 상태를 출력하자. 이는 클러스터에 참여중인 Node 를 확인 가능하다
- -o 옵션은 출력 방법을 지정하는 것이다. wide 를 통해 넓게 출력하여 클러스터에 참여중인 Node 의 추가 정보까지 출력하자
- 위와 같이 RUN 을 통해서 Pod 배포가 가능하다. 허나, 이번에는 재사용등을 고려해서 yml 파일을 통해 Pod 를 배포하겠다
3. API resource 와 namespace 확인
API resource 확인
Pod 를 만들기 위해서는 K8S 에서 제공하는 다양한 오브젝트 중 Pod 를 호출해야 한다. 이를 Api 를 통해 연결하여 생성할 수 있다
kubectl api-resources
- API 자원을 확인하자. 이는 리소스 정보를 확인 가능하며, 각 오브젝트에 대한 정보를 확인 가능 하다
- K8S 는 NAMESPACE 에 속하는 OBJECT 와 공유되는 OBJECT 가 있다. 이는 특정 NAMESPACE 에 속하지 않는 OBJECT 이다
- PV 는 영구 볼륨을 제공한다. PVC 는 PV 를 요청하는 것이다. 따라서, PV 는 다양한 사용자에게 제공되기에 NAMESPACE 에 속하지 않으며, PVC 는 각 사용자 별로 본인의 Pod 에 필요한 PV 에 대한 요청을 만드는 것이기에 NAMESPACE 에 속한다
- SHORTNAMES 는 줄임말 이다
- APIVERSION 도 확인 가능하다
- K8S 는 NAMESPACE 에 속하는 OBJECT 와 공유되는 OBJECT 가 있다. 이는 특정 NAMESPACE 에 속하지 않는 OBJECT 이다
- Pod 에 대한 API 자원의 정보를 확인하자
namespace 와 Pod 확인
- namespace 에 대해 확인하자. 기본적으로 Pod 배포시 default Namespace 에 속한다
- kube-system namespace 에 속한 Pod 가 있는지 확인해보자
- kube dns 는 worker 가 사용하며, node 당 하나씩 있다
- metrics server 는 master 가 사용한다
4. Pod 배포 및 확인
p. 106
K8S 를 사용하는 것은 사용자에게 POD 를 제공하는 것이다
- K8S 에서는 모든 오브젝트 ( POD, REPLICASET, DEPLOYMENT, SERVICE, CONFIGMAP / SECRET, PV / PVC ... ) 는 YML 파일 형태로 작성하여 배포가 가능하다. 이를 " Manifest File " 이라 부른다. 물론 명령을 통해서도 배포는 가능하지만, 재사용 등을 고려했을 때 파일 작성을 추천한다
- create 는 명령형이나 파일을 불러와서 배포하는 형으로 활용
- apply 는 파일을 이용하는 배포에 활용
Pod 생성시 master 에서 Pod 를 생성하여, namespace 등을 지정하여 worker 의 kubelet 에 해당 정보를 전달해준다. worker 는 runtime 을 통해 Pod 에 속할 container 를 생성한다
- namespace 와 같은 모든 정보는 master 에 존재한다
- 즉, master 에서 Pod 생성 후, namespace 를 지정하고, Container 생성을 위한 정보를 API 를 통해 worker Node 의 kubelet 에 넘겨주어, worker 의 runtime 에서 Container 가 생성되고, 해당 Container 의 정보를 master 의 etcd 에 넘겨준다
Pod 배포를 위한 yml 파일 작성
- 디렉토리를 만들고, 내부에 nginx 를 POD 로 배포하기 위한 yml 파일을 생성하자
- 위와 같이 작성하자
Pod 배포하기
배포전에 Docker 를 사용하므로, docker login 을 해주자
kubectl apply -f nginx-pod.yaml
- 위와 같이 yaml 파일을 apply 를 통해 배포하고, pod 를 확인하자
- 1/1 은 Pod 내부의 Container 개수이다
Pod 정보 확인하기
- Pod 의 정보를 넓게 출력하여 추가적인 정보를 확인하자
kubectl describe pod 'pod 이름'
- describe 를 통해 세부 정보를 확인할 수 있다
- namespace 는 기본적으로 default 로 정해진다
- Ip 는 있지만, 아직 외부 통신이 불가능하다. 외부 통신을 위해서는 반드시 Service 가 있어야 한다
- Events 를 확인하면, 먼저, 스케줄러가 kubelet 에게 명령을 전달한다. 이 kubelet 은 runtime 에게 명령을 내려 Pod 를 생성한다
- 명령 수행 후 kubelet 은 etcd 에 정보를 저장한다
- 모든 결과는 kubelet 을 통해 전달 받는다
- 스케줄러 부분은 master 에서 수행한 작업, kubelet 부분은 worker 에서 수행한 작업이다
- Container 에 대한 정보도 확인 가능하다. 이 Container 에는 Port 를 통해 접근한다
5. Pod 와 Container 접속
Pod 접속
- 먼저, Pod 에 들어가자. -it 옵션과 -- 를 통해 뒤에 실행할 명령어를 넣을 수 있다. 우리는 bash 를 실행했다
- 현재 우리는 Container 가 아닌, Pod 내부에 들어왔다. 여기서 Port 를 통해 Container 에 들어갈 수 있다
- 현재 우리는 Container 가 아닌, Pod 내부에 들어왔다. 여기서 Port 를 통해 Container 에 들어갈 수 있다
- localhost 는 현재 Pod 의 Ip 이다. Ip 는 Pod 에 한 개 할당되며, 안에 Container 들은 Port 로 접속이 가능하다. 따라서, Pod 내부의 Container 들에는 Ip 가 할당되지 않고, Port 로만 사용한다. localhost:80 을 하면, 현재 localhost 주소인 Pod 의 80 번 Port 를 사용하는 nginx Container 를 말하는 것이다
Pod 접속시 바로 Container 에 들어가는 이유는 Container 가 하나 있기 때문이다. 만약, Container 가 다수가 있다면 Port 를 지정해줘야 한다
Pod 삭제 및 배포 - Container 추가
- Container 를 한 개 더 추가하자. tail -f /dev/null 은 해당 파일의 내용의 마지막 내용을 계속 확인하게 하여 centos 를 꺼지지 않게 유지하기 위해 넣은 옵션이다
- 전에 생성한 Pod 를 삭제하고, 다시 배포하자. 삭제시 -f 를 사용하면, 해당 파일로 생성된 모든 것이 삭제된다
- Pod 정보를 확인해보면, Container 2 개가 잘 동작한다
- 세부 정보를 확인해보자
내부 Container 에 접속
- -c 옵션을 통해 Pod 내부의 Container 를 직접 지정하여 접속이 가능하다
- 우리는 centos 컨테이너에서 nginx 컨테이너에 접속이 가능하다
- 한 개의 Pod 내부의 컨테이너들은 자원을 공유한다. NIC 또한 공유하므로 Ip 는 Pod 의 Ip 를 사용한다. 따라서 어느 컨테이너든 localhost 는 Pod 의 Ip 로 동일한 것이다
멋진 엔지니어가 될 때까지