반응형

지난달 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
반응형
반응형

험난하고 많은 일이 있었던 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
반응형
반응형

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
반응형
반응형

static pod 에 대해서 알아보다가 몇가지 기억할 만한 것들을 적어본다.

- master node 의  /etc/kubernetes/manifests 하위에는 yaml 파일들이 있는데 이 yaml 파일들은 마스터 노드가 실행시에 자동으로 생성되는 static pod 들이다. 보통 etcd, api-server등이 있다.

- node에 생성된 static pod 를 지우기 위해서는 해당 노드에 가서 지워야 한다. 지우기 위해서는 노드 안에 있는 kubelet의 config 파일(/var/lib/kubelet/config.yaml) 에 있는 staticPodPath 값을 찾아서 path 위치에 있는 yaml 파일을 지워야 한다. kubectl delete pod 로 지우면 다시 생성된다.

- 조회는 가능하지만 edit 는 불가능 하다.

 

728x90
반응형
반응형

Lens 라는 툴을 사용해 보려고 host pc 에서 VM 에 있는 K8S 를 연결시켜보려고 시도를 해봤다.

2021/01/05 10:08:52 http: proxy error: x509: certificate is valid for 10.96.0.1, 10.0.1.7, not [ip]

그런데 위와 같은 에러 메세지가 나면서 연결이 되지 않았다. 위에 [ip] 는 host pc 의 ip 이다.

Google에서 찾아보니 인증서에 나의 로컬 ip 가 들어가 있지 않아서 라는 이야기가 나왔다.

그럼 현재 k8s 에 있는 apiserver 인증서 내용을 살펴보자.

openssl x509 -in /etc/kubernetes/pki/apiserver.crt -text

위와 같이 입력하면 apiserver.crt 파일에 있는 내용을 출력해서 볼 수 있다. 출력되는 항목중에 Subject Alternative Name 이라는 항목이 있다.

 X509v3 Subject Alternative Name:
                DNS:kubernetes, DNS:kubernetes.default, DNS:kubernetes.default.svc, DNS:kubernetes.default.svc.cluster.local, DNS:master01-virtualbox, IP Address:10.96.0.1, IP Address:10.0.1.7

여기 정보를 보면 10.96.0.1, 10.0.1.7 로 정의 되어 있다. 이곳에 내 로컬pc 의 ip 가 정의되어있어야 인증서 오류가 안나게 된다. 그럼 어떻게 해야 저부분을 수정을 할수 있나.

kube-system 네임스페이스에 있는 configmap 중에 kubeadm-config 라는 항목이 있다.

kubectl -n kube-system get configmap kubeadm-config -o yaml

apiVersion: v1
data:
  ClusterConfiguration: |
    apiServer:
      extraArgs:
        authorization-mode: Node,RBAC
      timeoutForControlPlane: 4m0s
    apiVersion: kubeadm.k8s.io/v1beta2
    certificatesDir: /etc/kubernetes/pki
    clusterName: kubernetes
    controllerManager: {}
    dns:
      type: CoreDNS
    etcd:
      local:
        dataDir: /var/lib/etcd
    imageRepository: k8s.gcr.io
    kind: ClusterConfiguration
    kubernetesVersion: v1.19.2
    networking:
      dnsDomain: cluster.local
      podSubnet: 10.244.0.0/16
      serviceSubnet: 10.96.0.0/12
    scheduler: {}
  ClusterStatus: |
    apiEndpoints:
      master01-virtualbox:
        advertiseAddress: 10.0.1.7
        bindPort: 6443
    apiVersion: kubeadm.k8s.io/v1beta2
    kind: ClusterStatus
kind: ConfigMap
metadata:
  creationTimestamp: "2020-10-12T10:21:12Z"
  managedFields:
  - apiVersion: v1
    fieldsType: FieldsV1
    fieldsV1:
      f:data:
        .: {}
        f:ClusterConfiguration: {}
        f:ClusterStatus: {}
    manager: kubeadm
    operation: Update
    time: "2020-10-12T10:21:12Z"
  name: kubeadm-config
  namespace: kube-system
  resourceVersion: "168"
  selfLink: /api/v1/namespaces/kube-system/configmaps/kubeadm-config
  uid: 93b6e988-686e-449b-9bd1-a6f02b15d1ea

위처럼 정의 되어있다.

update 를 위해서는 다음과 같이 명령어로 수행해 볼 수 있다.

kubeadm init phase certs --apiserver-cert-extra-sans stringSlice
Optional extra Subject Alternative Names (SANs) to use for the API Server serving certificate. Can be both IP addresses and DNS names.

(kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-certs)

kubeadmin init phase certs apiserver --apiserver-cert-extra-sans "추가할 IP"

그런데 먼저 하기전에 한가지 더 할 일이 있다.

/etc/kubernetes/pki 에 있는 apiserver.key, apiserver.crt 파일을 다른곳에 옮겨야 한다. 그렇지 않으면 인증서가 새로 생성되지 않는다. 다른 위치에 옮기고 나서 명령어를 실행한다.

sudo kubeadm init phase certs apiserver --apiserver-cert-extra-sans=X.X.X.X
I0105 11:06:44.899381    1295 version.go:252] remote version is much newer: v1.20.1; falling back to: stable-1.19
W0105 11:06:46.225883    1295 configset.go:348] WARNING: kubeadm cannot validate component configs for API groups [kubelet.config.k8s.io kubeproxy.config.k8s.io]
[certs] Generating "apiserver" certificate and key
[certs] apiserver serving cert is signed for DNS names [kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local master01-virtualbox] and IPs [10.96.0.1 10.0.1.7 X.X.X.X]

위와같이 실행 결과를 볼수 있다. 실제 인증서를 확인해 보면 다음과 같이 들어가 있다.

 X509v3 Subject Alternative Name:
                DNS:kubernetes, DNS:kubernetes.default, DNS:kubernetes.default.svc, DNS:kubernetes.default.svc.cluster.local, DNS:master01-virtualbox, IP Address:10.96.0.1, IP Address:10.0.1.7, IP Address:X.X.X.X

그런데 다시 Lens 로 접속 해보니 에러 발생

2021/01/05 13:14:53 http: proxy error: x509: certificate signed by unknown authority

그래서 결국 configmap 도 수정해주고 재기동 한 결과 정상적으로 접속이 됐다.

apiVersion: v1
data:
  ClusterConfiguration: |
    apiServer:
      certSANs:
      - X.X.X.X

 

728x90
반응형
반응형

ConfigMap

  • 컨테이너에 필요한 환경 설정을 컨테이너와 분리해서 제공하는 기능

사용

  • 설정
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: config-dev
    data:
      DB_URL: localhost
      DB_USER: myuser
      DB_PASS: mypass
      DEBUG_INFO: debug  
  • 컨피그맵 일부만 사용
    spec:
      containers:
      - name:
        image:
        env:
        - name: DEBUG_LEVEL
          valueFrom:
            configMapKeyRef:
              name: config-dev
              key : DEBUG_INFO
    • .env[].valueFrom 사용
    • .env[].valueFrom.configMapKeyRef 를 통해 이미 정의된 configmap 사용
  • 컨피그맵 전체를 불러오기
    spec:
      containers:
      - name:
        image:      
        envFrom:
        - configMapRef:
          name: config-dev      
  • volume 에 바인딩 하기
    spec:
      containers:
      - name:
        image:
        volumeMounts:
        - name: config-volume
          mountPath: /etc/config
      volumes:
      - name: config-volume
        configMap:
          name: config-dev    
    • 컨테이너 내부에 파일로 저장한다.
      root@nginx-deployment-67b8444cdf-sp7lx:/# ls /etc/config/
      DB_PASS  DB_URL  DB_USER  DEBUG_INFO

출처 : 쿠버네티스 입문 - 90가지 예제로 배우는 컨테이너 관리자 자동화 표준 (동양북스)

728x90
반응형
반응형

Ingress

개념

  • 클러스터 외부에서 안으로 접근하는 요청들을 어떻게 처리할지 정의해둔 규칙
  • 인그레스는 규칙들의 모음이며 실제로는 인그레스 컨트롤러가 동작시킨다.

설정

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: test
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: foo.bar.com
    http:
      paths:
      - path: /foos1
        pathType: Prefix
        backend:
          service:
            name: s1
            port:
              number: 80
      - path: /bars2
        pathType: Prefix
        backend:
          service:
            name: s2
            port:
              number: 80
  - host: bar.foo.com      
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:      
          service:
            name: s2
            port:
              number: 80  
  • annotation 은 인그레스 컨트롤러마다 다르다. (https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/)

    ingress version 차이

  • 1.18

    apiVersion: networking.k8s.io/v1beta1
    kind: Ingress
    metadata:
      name: test-ingress
      annotations:
        nginx.ingress.kubernetes.io/rewrite-target: /
    spec:
      rules:
      - http:
          paths:
          - path: /testpath
            pathType: Prefix
            backend:
              serviceName: test
              servicePort: 80
  • 1.19

    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: minimal-ingress
      annotations:
        nginx.ingress.kubernetes.io/rewrite-target: /
    spec:
      rules:
      - http:
          paths:
          - path: /testpath
            pathType: Prefix
            backend:
              service:
                name: test
                port:
                  number: 80

SSL 설정

  • tls 생성
    openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout tls.key -out tls.crt -subj "/CN=kube-book.com"
    Can't load /root/.rnd into RNG
    140377540018624:error:2406F079:random number generator:RAND_load_file:Cannot open file:../crypto/rand/randfile.c:88:Filename=/root/.rnd
    Generating a RSA private key
    ........................+++++
    ........+++++
    writing new private key to 'tls.key'  
  • tls secret 생성
    kubectl create secret tls kube-book-secret --key tls.key --cert tls.crt  
  • .spec.tls 설정
    spec:
    tls:
    - hosts:
      - kube-boo.com
      secretName: kube-book-secret

무중단 배포시 주의 할점

  • maxSurge 와 maxUnavailable 설정
    • maxSurge : 디플로이먼트에 기본 pod 개수에 여분의 파드를 몇개 추가 할수 있는지 설정
    • maxUnavailable : 디플로이먼트 업데이트시 사용할수 없는 파드 개수
  • readinessProbe 확인
    • 실제 서비스 요청 처리할 준비가 되었는지 진단
    • 설정 불가능할 경우 .spec.minReadySeconds 설정. 해당 설정 기간동은 트래픽을 받지 않지만 그 이후에는 받는다.
  • graceful 종료
    • 기존 받은 요청만 처리하고 새 요청은 받지 않는다
    • 설정 불가능 할 경우 hock 을 설정한다.

출처 : 쿠버네티스 입문 - 90가지 예제로 배우는 컨테이너 관리자 자동화 표준 (동양북스)

728x90
반응형
반응형

Service

개념

  • 동적으로 변하는 Pod 들을 고정적으로 접근할 때 사용한다.
  • 서비스는 주로 L4영역에서 통신할 때 사용한다.

서비스 타입

  • ClusterIP
    • default, 클러스터 내부에서만 사용가능
  • NodePort 모
    • 모든 노드에 지정된 포트를 할당함.
    • 외부에서 접근 가능
  • LoadBalancer
    • EXTERNAL-IP 생성
    • 외부에서 Pod 접근 가능 할수 있게 해줌
  • ExternalName
    • 서비스를 .spec.externalName 필드에 설정한 값과 연결한다.
    • 클러스터 안에서 외부에 접근할 때 주로 사용한다.

서비스 사용

  • 설정

    apiVersion: v1
    kind: Service
    metadata:
      name: my-service
    spec:
      type: ClusterIP
      selector:
        app: MyApp
      ports:
      - protocol: TCP
        port: 80
        targetPort: 8080
    • .spec.clusterIP 값을 None 로 설정하면 IP 가 없는 서비스 생성 가능

kube-proxy

  • userspace 모드
    • Pod 연결 요청시 실패할 경우 다른 Pod에 연결을 재시도함.
  • iptables 모드
    • 클라이언트 요청을 iptables 를 거쳐 Pod 로 직접 전달
    • Pod 연결 요청시 실패할 경우 재시도 안함
  • IPVS 모드

출처 : 쿠버네티스 입문 - 90가지 예제로 배우는 컨테이너 관리자 자동화 표준 (동양북스)

728x90
반응형

+ Recent posts