By oneself

매니페스트란 쿠베네티스의 오브젝트를 생성하기 위한 메타 정보를 yaml이나 json형태로 정의한 파일이다.

아래는 nginx 이미지로 pod 1개를 생성하는 yaml이다.

실제로 아래 명령어로 create해보자.

이제 검색을 해보면 아래와 같이 잘 떠 있는 것을 볼 수 있다.

지우는 것도 아래와 같이 간단하다.

yaml을 만들때 아래 4개가 필요하다.

• apiVersion : api버전 명시
• kind : 어떤 오브젝트의 종류를 설정할 것인지
• metadata : 이름이나 네임스페이스 같은 메타데이터를 지정한다
• spec : 실제 pod같이 실행될때 필요한 여러 스펙들을 명시

더 자세하고 필요한 내용들은 아래 링크에서 찾아보자

https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/

이제 아까 생성한 nginx pod에 접근해보려 하는데, 이 pod와 통신해볼 다른 pod를 생성해보자

위 명령어를 통해 busybox pod를 생성할 수 있고 접속까지 된다.

이후 위에서 생성했던 nginx pod의 ip주소를 알기위해 

를 통해서 ip주소를 기록해놓는다.

접속된 busybox안에서 wget {nginx_pod_ip}를 하면 index.html이 떨어지는 것을 볼 수 있다.

정상적으로 통신한 것이다. 이렇게 pod끼리는 내부에서 통신이 가능하다. 

이러한 pod가 통신이 된다는 것은 pod가 통신이 가능한 상태로 살아 있다는 뜻이다.

하지만 이를 가능하게 해주는 컴포넌트가 대략 2개가 있다.

• Liveness Probe
• Readiness Porbe

Liveness Probe는 정상적으로 pod가 실행되었다는 뜻이다. 만약 이상이 있으면 pod를 종료후 restart하게 된다. ymal에 명시되어 있어야 한다.

Readiness Probe는 정상실행중인 pod안에서 컨테이너 애플리케이션이 정상적으로 요청을 실제로 받을 수 있는지를 체크하는 놈이다. 검사에 실패하면 iptable에서 제외시켜 트래픽을 받지 않는다

이를 확인하는 구체적인 방법으로는 아래와 같이 4개를 제공한다

• command
• http
• tcp       
• gRPC

자신의 서비스나 설계에 맞는 방법을 쓰면 되지만 http를 제일 많이 사용하는듯 하다.

아래는 kubernetes 공홈에 나온 예제인데, 아래와 같이 설정을 해주면 된다. 아래는 command를 이용한 설정

아래는 http를 이용한 설정

pod는 쿠버네티스의 가장 기초라고 할 수 있다. 우리가 만든 어플리케이션이 실제로 pod단위로 기동되기 때문이다. 따라서 평소에 운영할때 적절한 pod의 수도 테스트 후 운영해야하며, 적절한 자원을 할당해야 한다. 또한 pod의 에러를 확인 후 트러블슈팅하는 능력도 중요하다.

아래 명령어로 pod하나를 기동시켜보자 

pod이름은 hello-world이고 이미지도 똑같다. --restart는 pod의 restart 정책을 설정하는 것이다. Always, OnFailure, Never가 있다.

pod를 검색해보면 아래와 같이 하나가 생긴것을 알 수 있으며 상태는  Completed이다. restart는 0으로 에러가 없이 잘 수행된 것 같다.

해당 파드를 지우고 싶으면 아래와 같이 delete 명령어를 사용하면 되며, 네임스페이스가 있는 경우  꼭 지정해줘야 한다.

이후 다시 pod검색을 하면 아래와 같이 default  namespace에 해당하는 pod가 없다고 나온다.

앞서 살펴봤지만, 다시한번 pod가 생기는 과정을 간략하게 보자면 아래와 같다.

1. kubectl명령어를 api -server가 받는다

2. etcd를 확인한다.

3. 컨트롤러와 스케쥴러가 동작한다.

4. kubelet에게 명령을 준다

5. 노드에 이미지가 없으면 원격 레포지터리에서 다운로드한다.

6. 노드의 containerd가 컨테이너를 실행한다.

그리고 해당 pod의 log를 보고싶으면 logs명령어를 아래와 같이 사용한다.

그럼 아래와 같이 해당 pod에 대한 log가 출력된다.

이번에는 디플로이먼트를 생성하고 디플로이먼트가 pod를 생성하는 것을 보자. 아래와 같이 입력하면 디플로이먼트가 생성된다.

이후 디플로이먼트를 검색하면 아래와  같이 출력된다.

항상 kubectl run을 통한 pod단독실행보다는, 디플로이먼트 yaml을 생성하고 관리하는것을 추천한다.

아래와 같이 nginx를 띄우는데 replicas 명령어를 통해 pod 5개를 기동시켜보자

아래와 같이 5개가 잘 running되고 있는것을 볼 수 있다.

실제로 쿠버네티스를 운영할때 명령어를 많이 사용했던것 같다.

get

create -f

delete -f

describe 

logs

사실 이 선에서 거의 끝난던것 같다. 나머지는 yaml 을 통한 버저닝, 트러블슈팅이 중요했다.

자 이번에는 Dockerfile을 통해 도커컨테이너를 실행시켜보자.

vi Dockerfile을 통해 만든다.

1. FROM alpine:latest

2. RUN apk update && apk add figlet

3. ADD ./message /message

4. CMD cat /message | figlet

위와 같이 설정했다.

1.번째 라인은 도커 베이스 이미지로 alpine 최신버전을 사용한다는 의미이다.

2.번째는 RUN을 통해 특정 cli명령어를 실행시키는 부분이다.

3. ADD는  파일시스템을 추가하는 부분이다.

4. CMD는 컨테이너 기동시 실행할 커맨드를 지정하는 것이며 cat이 실행된다. 

CMD 와 ENTRYPOINT 차이는 검색해보자

Dockerfile을 만들었으면 이미지를 만들어야 한다.

docker build--tag test:v0.1 . 

위와 같이 실행하면 test의 이름와 v0.1 태그로 이미지가 생성이 된다.

이후 앞선 설명화 같이 docker run 을 하면 실행이 된다.

docker ps 를 하면 실행중인 도커컨테이너를 볼 수 있다.

dockerfile을 만드는데 필요한 cheet들은 아래 글을 참고하자.

https://kapeli.com/cheat_sheets/Dockerfile.docset/Contents/Resources/Documents/index

dockerfile을 이용하는 이유는 다양하겠지만 개인적으로는 멱등성이라고 생각한다. 하나의 이미지를 사용하는 모든 사람들은 배포시 같은 환경이 되어야 한다. 또한 Iaac ( infra as a code)라는 개념과 같다. 인프라를 code로 관리하여 버저닝하는것이 운영에도 유리하다.