반응형
  • Image 를 export 하는 방법

docker save [option] [tar filename] [image name]

REPOSITORY   TAG       IMAGE ID       CREATED       SIZE
nginx        latest    fa5269854a5e   2 weeks ago   142MB

docker save -o test.tar fa5269854a5e

 

  • 실행중인 컨테이너를 export 하는 방법

docker export [container name or containter ID] > [tar filename]

CONTAINER ID   IMAGE          COMMAND                  CREATED          STATUS          PORTS                NAMES
791601bf0587   nginx:latest   "/docker-entrypoint.…"   33 minutes ago   Up 33 minutes   0.0.0.0:80->80/tcp   mystifying_benz

docker export 791601bf0587 > test.tar

 

 

728x90
반응형
반응형

지난달 CKA 자격증 취득에 이어서 CKAD 자격증도 따게 되었다. 이것도 작년에 사놓은 바우처가 올해 12월 까지 였는데 CKA 자격증 준비하면서 공부했으니 잊어버리기 전에 같이 해보는게 좋을것 같다는 생각을 했다. CKAD 를 먼저 본 분들의 후기를 보면 최근에 본 글들이 많이 없었다. 거의다 작년에 변경되기 전에 시험을 보신분들이 많았다. 일단 변경된 시험 범위는 아래 와 같다. 

출처 : https://github.com/cncf/curriculum/blob/master/CKAD_Curriculum_v1.23.pdf

  • CKA 와 CKAD 문제 구성의 차이점

- docker, heml

CKA 준비할때에는 k8s 의 리소스를 생성하고 수정하는 것은 많이 연습을 해봤는데 docker 나 helm 까지는 많이 해보지는 않았다. 그래서 부랴부랴 udemy 강의에서 변경된 부분에 대한 강의만 다시 들어보았다. 강의와 연결된 실습도 크게 어려움없이 풀었다. 문제에서는 이미지를 build 하고 이미지를 export 하는 문제가 나왔었다. 

- job, cronjob

job 을 생성하는 문제, cronjob 을 생성하는 문제들이 다양하게 섞어서 나왔다. 특히 job 에 대한 옵션들을 많이 주어지는데 그런 부분들을 다 반영해서 만들어야 한다. 

- probe

job 만큼이나 많이 나온 문제이다. probe 를 생성하는 문제, probe 때문에 pod 가 기동이 안되고 있는데 수정하라는 문제등의 문제가 나왔었다. 

- securtyContext

이부분은 serviceAccount와 연계해서 나온 문제들이었는데 sa를 생성해서 pod 에 정의해주라는 문제와 pod 로그를 보고 문제점을 해결하라는 문제였는데 그건 sa 이름이 실제와 이름이 달라서 생긴 문제였었다. 

  • 문제를 잘 읽자

CKA 시험과 마찮가지로 문제의 요구사항이 한가지가 아닌경우가 많다. 문제를 끝까지 읽어야 하고 주어진 조건을 반드시 모두 반영을 해야 한다. 그리고 문제에 Pod 를 수정하거나 삭제하지 말고 진행하라는 요구사항들도 주의깊게 봐야 한다. 영어를 번역하는데 헷갈린다면 구글 번역기 크롬 플러그인을 깔아서 확인해보는것도 방법이다. 이것은 문제 삼지 않는다.

  • 결과

총 16문제였는데 문제 하나하나 마다 대부분 배점이 높아서 정말 난감했다. 4점짜리는 많이 못본것 같다. 그리고 진짜 시간이 부족했다. 내가 몰라서 찾아본것이 있어서 그런것도 있겠지만 CKA 시험보다는 시간이 정말 빠듯했다. 그래서 마지막에 내가 완벽히 못푼 문제들의 배점을 세어봤다. 그랬더니 34점 점도가 됐었다. ㅡ,.ㅡ;;; 통과 점수는 66점인데 34점이면 완벽히 못푼 문제들을 제외하고 나머지는 다 맞아야 한다는 결론이었다. 이 34점 중에 8점자리 하나는 "맞겠거니" 라고 생각했던 문제가 있었는데 74점인거 보면 아마도 그게 맞지 않았나 싶다. 실제 결과는 알수가 없지만..

그래서 예상을 하기에 66점으로 딱 pass하거나 떨어지면 근소한 차이로 또 떨어지겠거니 했는데 다행스럽게도 pass를 했다. 물론 만족할 만한 점수는 아니지만 그래도 붙어서 다행이다.

자격증을 땄다고 해서 그걸 잘 아는것은 아니기 때문에 앞으로도 더 공부를 해야 하겠지만 지난번 시험이후에 또 한가지 무언가를 했냈다는데에 큰 기쁨을 얻었다. 

728x90
반응형
반응형

K8S의 container 에 정의되는 args 와 command 에 대한 차이점은 다음과 같다. 

Docker image 빌드시에 ENTRYPOINT 와 CMD 를 정의 할 수 있다.

ENTRYPONT : 컨테이너가 실행될 때 반드시 default 로 실행된다. 따라서 컨테이너가 수행될 때 변경되지 않을 실행명령은 ENTRYPOINT 로 정의하는게 좋다.
CMD : 컨테이너 실행시 파라메터를 추가 하게 되면 추가된 파라메터를 실행시킨다. 

이때 k8s 에서 정의하는 args 는 Docker 이미지의 CMD 에 바인딩 되고 command 는 ENTRYPOINT 에 바인딩 된다. 이름때문에 command가 CMD 에 바인딩된다고 착가하면 안된다.

 

728x90
반응형
반응형

험난하고 많은 일이 있었던 CKA 자격증 시험을 준비하는 과정과 시험 과정에서 발생했던 어이없는(?) 상황에 대해서 이야기 해보려한다.

이야기 순서는 다음과 같다. 

1. CKA 시험 준비
2. 2번의 Fail.
3. 다시 바우처 구입과 재시험 & 시험봐야 하는데 Proctor는 어디에??
4. 합격 후기
5. 남겨진 문제들

그럼 이야기를 시작해보자.

1. CKA 시험준비

지금이 2022년이고 어느덧 4월이다. 나는 바우처를 작년 5월에 구입을 했다. 올해도 똑같은 해택을 줄지는 모르겠지만 작년에 있었던 Virtual KubeCon 을 참석한 혜택으로 50% 할인 가격으로 CKA 바우처를 구입할수 있었다. 그리고 나도 CKA를 응시했던 많은 분들이 들었던 Udemy 강의(Certified Kubernetes Administrator (CKA) with Practice Tests)도 구입해서 공부를 하기 시작했다. K8S 를 많이 사용하지는 않았지만 가끔 사용할 일이 있어서 관심은 있었고 뭔가 배우면서 재미있어서 공부를 했었다. 그러다가 시험을 봐야지 봐야지 하면서 미루다가 어느덧 바우처 만료일이 2022년 5월이라는것을 알고 다시 준비하기 시작했다. 강의에 있는 Mock Exam 도 풀어보고 여기저기 블로그의 글들도 많이 찾아봤다. 시험에 관련된것 보다는 아래 부분에서 불편함이 컸다. 

- 사이트가 느려도 너무 느리다.

바우처를 구매하고 시험을 신청하기 위해서는 시험 신청화면에서 Schedule 버튼을 누르게 되어있다. 그러면 아래와 같은 화면이 나온다.

저 화면에 나오기 전에 날짜와 타임존을 선택화면이 나오는데 거기서부터 인내심이 아주 많이 요구된다. 분명 달력 조회하는 화면인데 처음 하다보면 한번 조회할때마다 2~3분은 기본이다. 저 화면에서도 날짜를 선택하고 아래 Time 이 나오는데 저 결과도 당연히 바로바로 안나온다. 심지어 조회 결과가 누를때마다 다르게 나오는 경우도 있다. 스터디룸 예약시간하고 시험 시간을 맞춰야 해서 시험시간을 조회했는데 처음에는 없었던 Time 이 다시 조회하니깐 나오는 신기한 경우를 자주 목격했다. 그렇기 때문에 본인이 원하는 시간이 Time 항목에 없을 경우 다시 한번 조회를 시도해보는게 좋다. 

- 신분증

신분증은 보통 여권을 사용하는게 좋다고 했는데 난 이미 여권이 만료되어서 여권을 따로 만들어야 하나 생각을 했었다. 그러다가 신용카드를 보여줘도 괜찮다는 글들이 있어서 여권은 안만들기로 했다. Proctor 가 id 를 요구할때 운전면허증과 신용카드를 차례대로 보여줬다. 운전면허증만 보여줘서는 안되는것 같고 반드시 영문으로 적힌 이름이 있는 ID 가 필요한것 같다. 그리고 카드를 보여준후 뒷면의 사인 부분도 보여달라고 한다. 난 사인이 내 한글 이름으로 써있는데 그것까지는 문제삼지 않았다. 

2. 2번의 Fail

위 결과를 보면 알수 있듯이 난 1개의 바우처에서 사용할수 있는 2번의 기회를 다 놓쳤다. Score 를 보면 처음에는 62, 두번째는 64 였다. 처음 시험보고 62가 나와서 내가 좀 갸웃거렸던 문제들을 다시 생각해서 좀 찾아보고 다시 재시험을 봤다. 그런데 최소한 첫번째 시험보다는 두번째에서 더 풀었다고 생각했었는데 점수차이가 별로 나지 않았다. (참고로 나같은 경우는 첫시험과 두번째 시험이 거의 동일하게 나왔다. 매번 그러는지는 모르겠으나 나중에 3번째 시험볼때도 거의 비슷하게 나왔다.) 결론적으로 비슷한 문제를 다시 비슷하게 풀어서.. 같은 문제 또 틀렸다는 이야기이다. 대체 왜?? 처음 시험보다 몇개는 더 결과를 냈기 때문에 최소한 2점보다는 더 오를거라 생각은 했는데 이모양이라니.?

2번의 시험을 다 떨어지고 망연자실 하다가 다시 인터넷을 검색해봤다. 내가 풀었던 문제들의 키워드 중심으로 검색을 다시 해봤는데 비슷한 문제풀이를 해놓은 블로그들이 있었다. 그래서 그 글들을 천천히 읽다 보니 문제점이 뭐였는지 알게 되었다. 문제점은 다름 아닌 영어 해석을 잘못했거나 조건을 끝까지 보지 않아서 잘못본것이다. 정말 그렇게 찾아보고 나니 더 허탈한 마음을 지울수가 없었다. 약간 멘탈이 나갔다고 해야 하나.

바우처를 다시 사서 해야 하나 아니면 할인을 기다릴까 라는 고민들이 깊어질 찰라에 25% 할인을 해서 일단 바우처를 구매를 했다. 그리고 시험을 언제볼까하다가 다시 한번 도전했다. 3주에 걸쳐서 주말마다 시험을 봤다. 이제는 기필고 완료하겠다는 다음을 하고 지난 주말 토요일 오전에 스터디룸에 가서 시험을 보게 되었다. 그런데 정말 가장 황당한 일이 이때 벌어졌다. 

3. 시험봐야 하는데 Proctor는 어디에??

내가 예약한 시간은 오전 11시부터 오후 1시였다. Take Exam 버튼은 15분 전에 활성화가 되기 때문에 10시 45분에 접속을 했다. 두번째 시험때에는 시험시간전에 미리 접속을 했더니 Proctor 가 시험시작시간 전에 id 체크랑 룸 체크를 해서 그생각을 하고 미리 접속했다. 그런데 이번에는 11시 전에 아무 반응이 없었다. 아래 보여지는 화면만 볼수 있었다. 그래서 이번 Proctor 는 정시부터 시작하려나?? 생각하고 있었다. 

그런데 시험시간인 11시가 되어도 위 화면만 계속 나왔다. 그렇게 한 20분정도 보냈다. 그러다가 안되겠다 싶어서 위에 적힌 전화번호중 첫번째 번호로 전화를 했다. 전화를 하니 당연히 영어로 나온다. 한참 듣다가 psi support 어쩌고 하길래 그건가 싶어서 번호를 누르고 기다렸다. 다행히 상담원이 전화를 받는데 당연히 외국인이다. 짧은 영어로 상황을 설명하고 나니 뭔가 체크를 했다. 내 운영체제랑 os 버전등. 아마도 jira 같은걸로 상담을 관리하는데 거기에 적어야 되는 항목인것 같았다. 그런데 이야기를 하다보니 내 노트북에 공유 문제인것 같은 체크를 계속 하길래 전에도 동일한 시험을 동일한 장소에서 동일한 노트북으로 했고 내 장비에는 문제가 없다고 이야기를 했다. 그리고 한참 이야기를 하더니만 공유프로그램 깔아달라고 해서 깔아주고 상담원이 내 노트북에 원격 접속해서 체크를 했다. 

체크 결과 당연히 내 장비에는 문제가 없었다. 그리고 쫌만 기다려 달라고 계속 하고 뭔가 상황이 나아지지는 않았다. 왜 Proctor 가 안온건지, 아니면 할당이 안된건지, 지금 시험을 진행할수 있는 Proctor 가 있는지 물어봤지만 정확히 대답을 해주지는 않았다. 

그러다가 내 노트북 원격으로 지원은 연결된 채로 전화가 끊겼다. 그때가 한시간정도 통화할때쯤이었다. 그래서 화면이 공유되고 있었기 때문에 내 노트북 브라우저에 핸드폰 전화번호를 적었다. 전화해달라고.. 그런데 한 10분 기다려도 전화가 안오길래 다시 전화를 했다. 그랬더니 다른 상담원이 전화를 받아서 처음에 했던 일을 반복하는 것이었다. 이때 상담원이 issue id 라는것을 말해줬는데 그 issue 아이디를 기존 상담원이 볼수 있도록 브라우저에 적었다. 그리고 나서 좀 이따가 상담원이 기존 상담원이 다시 전화를 할꺼라면서 전화를 끊었다. 그리고 몇분 있다가 다시 처음 상담을 했던 상담원에게 전화가 왔다. 

상담원이 다시 연결되고 일을 어떻게 처리 하는지는 모르겠지만 일단 기다렸다. 그리고 오늘 시험을 볼수 있냐고 물어봤더니 볼수 있다고 해서 난 그저 기다릴 수밖에 없었다. 그리고 시간이 더 흘러서 12시 45분쯤 되서 시험이 다시 시작되었다. 내가 예약한 스터디룸 시간이 10시 30분부터 1시 30분까지였는데 시험을 보기에는 충분치 않았고 2시 이후에 예약이 이미 잡혀있어서 바로 옆 룸을 예약해서 시험을 보게 되었다. 옆에 룸마저 예약이 되어있었다면 어찌 됐을지...

우여곡절끝에 12시 45분부터 사전체크를 하고 난 1시부터 120분간 시험을 보게 되었다. 이미 장시간 영어 통화로 인해서 기운이 다 빠진 상태였으나 일단 시험은 무난하게 잘 봤다. 시험을 끝내고 나니 기운이 다 빠졌다. 

4. 합격 후기

이상한 일을 겪긴 했지만 시험은 패스를 했다. 93을 예상했지만 85점인거 보니 내가 생각했던 문제 이외에 다른 문제도 틀렸나보다. 틀린것을 예상한 문제는 Ingress 를 생성해서 service 랑 연결하는 문제였는데 아무리 생각해도 제대로 한것 같은데 Ingress 의 ADDRESS 가 바인딩이 되지 않았다. 그래서 이문제는 틀리겠구나 싶었는데 그것 이외에도 다른 문제가 틀렸다니.. 뭐가 틀렸는지 궁금하긴 하지만 알 방법이 없다.

5. 남겨진 문제들

시험을 보고난 저녁에 LinuxFoundation 쪽에 문의 를 보냈다. 왜 이런 상황이 발생했는지. 그리고 내가 한시간넘게 통화한 국제 통화료는 처리가 될지 를 포함해서 문의를 보냈다. 통신사에 문의를 해보니 발생한 통화료는 55000원 정도, 부가세를 포함하면 6만원 정도가 된다. 한시간 넘게 통화한거라서 정말 많이 나올줄 알았는데 그래도 생각보다 덜나오긴 한것 같다. 일단 현재는 문의만 한 상태이고 처리에 대한 응답은 받지 못한 상태이다. 

참고 ) 1,2 차 탈락 후 광탈 한 후에 참고하게 된 사이트들 (시험에 나왔던 단어들 키워드로 검색한 결과.....문제가 다시 나온다는 보장은 모르겠음..)

https://daintree.tistory.com/18
https://ls-altr.tistory.com/82
https://programs.wiki/wiki/kubernetes-k8s-s-17-requirements-practice-tests.html

728x90
반응형
반응형

Network Policy 에 관한 설정들 참고할 만한것 몇가지 작성해본다.

아래 두개의 NetworkPolicy 는 아래 조건을 만족한다.

  • test1 네임스페이스에서 pod 끼리는 전부 호출 가능하다
  • test1 네임스페이스에서 test2로만 호출가능하며 포트는 80 포트를 사용한다. 
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: np
  namespace: test1
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
     - namespaceSelector:
        matchLabels:
         kubernetes.io/metadata.name: test2
  - ports:
    - port: 80
      protocol: TCP
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: np
  namespace: test2
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
   - from:
     - namespaceSelector:
        matchLabels:
         kubernetes.io/metadata.name: test1

위에 정의된 부분을 확인해보자면 다음과 같다.

  • podSelector: {} : 해당 네임스페이스의 모든 pod 에서는 호출 가능하다.
  • egress.to.namespaceSelector : 네임스페이스의 라벨을 정의함으로써 라벨이 일치하는 네임스페이스로 호출가능하다.
  • ingress.from.namespaceSelector : 일치하는 라벨의 네임스페이스에서반 inbound 접근이 가능하다.
  •  

확인을 위해서는 curl 을 이용한다.

  • 우선 서비스의 도메인 이름은 서비스이름.네임스페이스.svc.cluster.local 로 정의된다. 
  • 도메인에 대한 정보는 pod 의  /etc/resolv.conf 로 확인 가능하다.
728x90
반응형
반응형

docker 실행시 컨테이너 내부에서 컨테이너 외부 파일을 연결할수 있는 방법이 있다.

docker run 실행시 -v [호스트경로]:[컨테이너경로] 를 추가해주면 호스트 경로와 컨테이너 경로가 연결되게 된다. 한가지 중요한 점은 호스트 경로의 상태가 컨테이너 경로에 덮어써진다는 것이다. 

➜  docker docker run --name nginx-mounts -d -p 8081:80 -v /Users/Workspaces/docker:/usr/share/nginx/html nginx
Unable to find image 'nginx:latest' locally
latest: Pulling from library/nginx
7d63c13d9b9b: Pull complete 
15641ef07d80: Pull complete 
392f7fc44052: Pull complete 
8765c7b04ad8: Pull complete 
8ddffa52b5c7: Pull complete 
353f1054328a: Pull complete 
Digest: sha256:dfef797ddddfc01645503cef9036369f03ae920cac82d344d58b637ee861fda1
Status: Downloaded newer image for nginx:latest
f1aa047705f563a0db1f76abbadddf74ea2fff7542e55601a84eccf43dc207b4
➜  docker curl localhost:8081                          
<html>
<head><title>403 Forbidden</title></head>
<body>
<center><h1>403 Forbidden</h1></center>
<hr><center>nginx/1.21.4</center>
</body>
</html>

위에서는 docker를 실행할 때 /Users/Workspaces/docker 경로를 컨테이너 안에 /usr/share/nginx/html 에 바인드 시켰다. 기본적으로 nginx의 /usr/share/nginx/html 경로에는 index.html 파일이 존재하지만 현재 호스트의 /Users/Workspaces/docker 경로에는 아무것도 없는 빈 디렉토리이기 때문에 403 이 나온다.

 

728x90
반응형
반응형

1. docker inspect container_id
명령어를 치면 굉장히 많은 정보를 확인할 수 있다. 그래서 grep 으로 조회하면 좀 수월하다.
docker inspect container_id | grep IP

"LinkLocalIPv6Address": "",
"LinkLocalIPv6PrefixLen": 0,
"SecondaryIPAddresses": null,
"SecondaryIPv6Addresses": null,
"GlobalIPv6Address": "",
"GlobalIPv6PrefixLen": 0,
"IPAddress": "192.168.0.1",
"IPPrefixLen": 16,
"IPv6Gateway": "",
        "IPAMConfig": null,
        "IPAddress": "192.168.0.1",
        "IPPrefixLen": 16,
        "IPv6Gateway": "",
        "GlobalIPv6Address": "",
        "GlobalIPv6PrefixLen": 0,

2. docker exec -it container_id /bin/bash
위 명령어를 사용하면 컨테이너 내부로 접속이 가능하다. 내부로 접속을 해서 ip addr 이나 ifconfig, hostname -I 등을 사용해서 확인 가능하다. 

3. docker exec container_id command
exec 만 사용을 하고 후에 명령어를 치면 컨테이너 내부에 명령어를 보내 실행이 가능하다. 

 

728x90
반응형
반응형

history 명령어를 통해서 이미지가 어떤 과정을 거쳐 생성되었는지 확인해볼수 있다.

아래와 같이 nginx 의 latest 이미지와 stable 이미지에 대한 내역을 비교해볼수 있다.

root@myserver-001:~# docker history nginx:stable
IMAGE          CREATED       CREATED BY                                      SIZE      COMMENT
c8d03f6b8b91   4 weeks ago   /bin/sh -c #(nop)  CMD ["nginx" "-g" "daemon…   0B        
<missing>      4 weeks ago   /bin/sh -c #(nop)  STOPSIGNAL SIGQUIT           0B        
<missing>      4 weeks ago   /bin/sh -c #(nop)  EXPOSE 80                    0B        
<missing>      4 weeks ago   /bin/sh -c #(nop)  ENTRYPOINT ["/docker-entr…   0B        
<missing>      4 weeks ago   /bin/sh -c #(nop) COPY file:09a214a3e07c919a…   4.61kB    
<missing>      4 weeks ago   /bin/sh -c #(nop) COPY file:0fd5fca330dcd6a7…   1.04kB    
<missing>      4 weeks ago   /bin/sh -c #(nop) COPY file:0b866ff3fc1ef5b0…   1.96kB    
<missing>      4 weeks ago   /bin/sh -c #(nop) COPY file:65504f71f5855ca0…   1.2kB     
<missing>      4 weeks ago   /bin/sh -c set -x     && addgroup --system -…   63.9MB    
<missing>      4 weeks ago   /bin/sh -c #(nop)  ENV PKG_RELEASE=1~buster     0B        
<missing>      4 weeks ago   /bin/sh -c #(nop)  ENV NJS_VERSION=0.5.3        0B        
<missing>      4 weeks ago   /bin/sh -c #(nop)  ENV NGINX_VERSION=1.20.1     0B        
<missing>      4 weeks ago   /bin/sh -c #(nop)  LABEL maintainer=NGINX Do…   0B        
<missing>      4 weeks ago   /bin/sh -c #(nop)  CMD ["bash"]                 0B        
<missing>      4 weeks ago   /bin/sh -c #(nop) ADD file:910392427fdf089bc…   69.3MB    

root@myserver-001:~# docker history nginx:latest
IMAGE          CREATED        CREATED BY                                      SIZE      COMMENT
04661cdce581   45 hours ago   /bin/sh -c #(nop)  CMD ["nginx" "-g" "daemon…   0B        
<missing>      45 hours ago   /bin/sh -c #(nop)  STOPSIGNAL SIGQUIT           0B        
<missing>      45 hours ago   /bin/sh -c #(nop)  EXPOSE 80                    0B        
<missing>      45 hours ago   /bin/sh -c #(nop)  ENTRYPOINT ["/docker-entr…   0B        
<missing>      45 hours ago   /bin/sh -c #(nop) COPY file:09a214a3e07c919a…   4.61kB    
<missing>      45 hours ago   /bin/sh -c #(nop) COPY file:0fd5fca330dcd6a7…   1.04kB    
<missing>      45 hours ago   /bin/sh -c #(nop) COPY file:0b866ff3fc1ef5b0…   1.96kB    
<missing>      45 hours ago   /bin/sh -c #(nop) COPY file:65504f71f5855ca0…   1.2kB     
<missing>      45 hours ago   /bin/sh -c set -x     && addgroup --system -…   61.1MB    
<missing>      45 hours ago   /bin/sh -c #(nop)  ENV PKG_RELEASE=1~bullseye   0B        
<missing>      45 hours ago   /bin/sh -c #(nop)  ENV NJS_VERSION=0.7.0        0B        
<missing>      45 hours ago   /bin/sh -c #(nop)  ENV NGINX_VERSION=1.21.4     0B        
<missing>      45 hours ago   /bin/sh -c #(nop)  LABEL maintainer=NGINX Do…   0B        
<missing>      4 weeks ago    /bin/sh -c #(nop)  CMD ["bash"]                 0B        
<missing>      4 weeks ago    /bin/sh -c #(nop) ADD file:16dc2c6d1932194ed…   80.4MB

 

728x90
반응형
반응형

kubectl drain 노드명

- drain 명령어를 사용하게 되면 해당 노드의 pod 를 다른 노드로 옮긴다.
- 실제로는 pod 를 옮기는게 아니라 다른 노드에 재 생성한다.
- 데몬셋을 무시하고 진행할 경우에는 --ignore-daemonsets 옵션을 사용한다.

아래와 같이 myserver-002와 myserver-003 에 pod 가 각각 deploy 되어있다.

root@myserver-001:~# kubectl get po -o wide
NAME                            READY   STATUS    RESTARTS   AGE     IP          NODE           NOMINATED NODE   READINESS GATES
rollout-nginx-74695fdcd-5trw5   1/1     Running   0          3m55s   10.32.0.2   myserver-002   <none>           <none>
rollout-nginx-74695fdcd-jkw2d   1/1     Running   0          3m55s   10.47.0.2   myserver-003   <none>           <none>
rollout-nginx-74695fdcd-tp75z   1/1     Running   0          3m55s   10.47.0.1   myserver-003   <none>           <none>

이 상황에서 myserver-003 을 drain 을 시켜보면 다음과 같이 변경된다.

root@myserver-001:~# kubectl get nodes
NAME           STATUS                     ROLES                  AGE     VERSION
myserver-001   Ready                      control-plane,master   2d8h    v1.22.3
myserver-002   Ready                      <none>                 2d8h    v1.22.3
myserver-003   Ready,SchedulingDisabled   <none>                 4h23m   v1.22.3

 

root@myserver-001:~# kubectl get po -o wide
NAME                            READY   STATUS    RESTARTS   AGE     IP          NODE           NOMINATED NODE   READINESS GATES
rollout-nginx-74695fdcd-5trw5   1/1     Running   0          4m45s   10.32.0.2   myserver-002   <none>           <none>
rollout-nginx-74695fdcd-8c55f   1/1     Running   0          11s     10.32.0.3   myserver-002   <none>           <none>
rollout-nginx-74695fdcd-h6txz   1/1     Running   0          11s     10.32.0.4   myserver-002   <none>           <none>

기존에 있던 rollout-nginx-74695fdcd-5trw5 파드를 제외하고 나머지 pod 는 이름을 보면 새로 만들어진것이다. Age 도 11s 로 나온다. 따라서 위에서 말한것처럼 drain 을 했을 경우 pod 를 옮기는게 아니라 삭제하고 새로 만들게 된다. 

 

728x90
반응형

+ Recent posts