시골쥐의 공부생활

144. Certificates API
certificate를 관리하는 방법과 certificate API가 무엇인지 다룸.

나는 이미 admin으로서 인증서가 있는 상태인데, 
우리 부서에 새로운 직원이 오면, 클러스터에 어떻게 접근을 할까?

1. 그 사람을 위한 인증서 & key pair
 -  creates her own private key using CSR(Certificate Signing Req) to admin
 -  admin takes CSR and send it to his CA server
 -  hers certificate signed by CA server using CA servers private key/root certificate
 -  now she has her own valid pair of certificate and key
    (use to access to cluster)
 

* certificate는 validated pariod가 있고,   이게 종료되면 다시 동일한 CSR 절차를 통해 CA로부터 인증서를 승인받는다.
  - 그래서 계속 certificate file을 순환시키고 CA와 통신하는데  CA Server가 뭐고, k8s의 어디에 셋업이 될까?
  - 여러 인증서를 발급하다보니 안전한 환경에 있어야 한다.
  - 인증서들은 master node에 있고, 이건 곧 CA Server다.
  - 그런데 관리하는 인증서가 많아진다면? 매번 많은 작업이 요구된다.
  - 그래서 K8s는 자체적인 Certificate API를 제공한다.

 * Certificate API
 CSR을 k8s로 direct하게 보낼 수 있다.
 admin이 master node에 로긴하는 대신 CSR을 받으면, CSR이라는 K8s API object를 생성한다. 
object가 생성되면, 모든 CSR은 cluster의 admin에 보이게 된다.
 - 그럼 CSR은 k8s cmd를 통해 Review되고, Approved 된다. 
 - 그리고 인증서는 유저와 공유된다.

 - 다시 절차를 정리해보자
  1) A user creates a key
    # openssl genrsa -out jane.key 2048
  2) generates CSR using the key with her name in it.
  3) sends CSR to admin
    # openssl req -new -key jane.key -subj "/CN=jane" -out jane.csr

  4) admin create a CSR object
     jane.csr -> object
  5) CSR object의 definition file엔 key를 일일이 입력할 필요 없고, 
     base64 명령어를 통해 jane.csr의 key를 jane-csr.yaml의 spec>request:에 복붙 하면 된다.
    # cat jane.csr | base64 

  6) CSR object를 조회해본다
    # kubectl get csr
  7) new Request / approved Req를 확인해본다
    # kubectl certificate approve jane

  8) certificate는 YAML file으로도 확인할 수 있다. (base64)
    # kubectl get csr jane -o yaml

 그럼 생성은 다 됐으니, 어떻게 동작할까?
kube-api server, scheduler, controller manager이 certificate와 모두 관련있다.
그리고, 관련된 동작은 controller manager에 의해 캐리된다.
controller mgr에 csr-appriving, csr-signing 이라는 task가 있는데, 다음 강의에서 더 자세히 알아보자.

출처: Udemy 사이트의 Certified Kubernetes Administrator (CKA) with Practice Tests 강의
  

141. View Certificate Details
인증서를 조회하는 방법

인증서에 문제가 있을 때(health check) 뭘 확인해야할까?
1. 어떻게 cluster가 셋업 됐는지 확인하기
  - Hard way: 스스로 command를 통해 config 및 certification 작성해서 띄움
  - tool: kubeadm등을 통해 클러스터 자동 생성
* 올바른 정보를 확인하기 위해 어디를 봐야하는지 아는 것이 중요함.

 1) kube-apiserver definition file 확인(/etc/kubernetes/manifests 폴더) 및 정리
  - run 'openssl x509 command -in /etc/kubernetes/pki/apiserver.crt -text -noout
   . Subject 및 alternative name 확인
   . expiry date 확인 ('Validity'> Not After)
   . Issuer: CN-kubernetes 확인 

 2) pod log 확인
  # kubectl logs etcd-master

 3) docker log 확인 (pod가 down됐을 경우)
  # docker ps -a 

출처: Udemy 사이트의 Certified Kubernetes Administrator (CKA) with Practice Tests 강의

이전 강의에서 말한 TLS 정보들이 K8s에서 어떻게 사용되는지 알아보자.

크게 두 가지로 나뉜다.

1. Server Certificates for Servers

2. Client Certificates for Clients

1. Server Certificates for Servers

K8s 내 다른 컴포넌트끼리 통신하는 방법.

Api server는 https service를 expose하니까, 클라이언트들과 모든 통신을 암호화하기위해 인증서를 필요로한다.

그래서, Kube-API서버를 위한 apiserver.crt, apiserver.key를 만든다.

etcd, kubelet도 마찬가지다. 각자 정보를 저장하고, worker노드를 관리하기에 certificate와 key가 각각 필요하다.

2. Client Certificates for Clients

Clients는 service/k8s 에 access하는 사람/것(ex. administrator, kube-scheduler)

 - 사용자는 서버를 인증하기 위해 인증서와 keeper를 필요로 한다. 

 - scheduler는 kube-api server입장에서는 client로서, cleint certificate를 이용하여 그것의 id를 validate 해야한다.

  그래서 인증서와 key가 필요하다.

- kube controller mgr, kube-proxy도 동일하다.

- 그리고, kube-api 서버도 etcd 및 kubelet server와 통신할 땐 client가 된다. 그래서 새로운 인증서/키를 생성하거나

혹은 기존 것을 동일하게 사용한다.

점점 복잡해지니 그룹핑을 해보자.

결국 api, kubelet service는 client certificate도 가지고 있고, server certificate도 가지고 있다.

그럼 인증서는 어떻게 만들어질까?

이전 강의에서 본 것처럼, 인증서를 등록하기 위해서는 certificate authority(CA) 가 필요하다.

그리고, CA는 전체 인증서와 키의 짝을 들고 있으므로, ca.crt / ca.key를 생성하여 클러스터내 사용되는 모든 인증서를 합친다.

인증서를 생성하기 위해서는, 위와 같은 3개의 툴이 있다.

그리고 이 강의에서는 openssl을 다뤄본다.

key certificates를 만들기 위한 방법은 아래와 같다.

1) Generate Keys: private key를 생성한다 

#openssl genrsa -ou tca.key 2048

2) Certificate Signing Request

# openssl req -new -key ca.key -subj "/CN=KUBERNETES-CA" -out ca.csr 

디테일한 인증서 정보들이 포함되어 있고, component의 이름을 specify한다. (ex. CN)

예를 들어, CA를 위한 인증서를 만드니까, 그 것의 이름은 KUBERNETES-CA가 된다.

3) Sign Certificates

# openssl x509 -req -in ca.csr -signkey ca.key -out

인증서를 등록한다. 이제 CA는 그것의 Private와 root certificate를 가지고 있다.

이제 client certificate를 만들어보자.

admin 유저를 위한 인증서부터 시작하는데, 위 server 절차와 동일한 절차를 따른다.

1) Generate Keys: private key를 생성한다 

2) Certificate Signing Request

# openssl req -new -key admin.key -subj "/CN=kube-admin/OU=system:masters" -out ca.csr

3) Sign Certificates

# openssl x509 -req -in ca.csr -signkey ca.key -out

# openssl x509 -req -in admin.csr -CA ca.crt -CAKey ca.k 

// ca.crt가 추가된다: ca key pair와 인증서를 등록하기 때문. 이건 클러스터 내 유효한 인증서를 만든다.

key와 인증서를 생성하는 전체 절차는 usr account를 생성하는 절차와 비슷하다.

인증서는 validated user ID이고, key는 password 같기 때문인데, TLS는 훨씬 안전하다. 

그런데, 다른 user들과 해당 user를 어떻게 구분할까?

user 계정은 다른 basic user가 아니라, admin user의 id를 필요로 한다.

그렇다면, 이건 그룹 생성을 통해 해결해줄 수 있는데, 이 또한 인증서에 언급이 되어야 하므로

O=system:masters 옵션을 통해 CSR을 보내준다.

그럼, 이 인증서들과 무엇을 할까?

admin 인증서로는 cluster를 관리한다. curl 명령어로 username/password 대신 인증서를 사용할 수 있다.

다른 방법은, kube-config에 작성해놓는 것이다. 대부분의 client들이 이 방식을 사용한다.

+ cleint들은 server로부터 전달된 인증서를 validate하기 위해 CA public certificate copy가 필요하다.

(web app의 경우 user brower내에 자동으로 설치되어 있는)

k8s는 다양한 컴포넌트들이 있으므로, 서로를 검증하기 위해 root certificate 복사본을 각각 가지고 있다.

server side certificate의 예로 etcd 서버를 봐보자. 동일한 절차를 따르는데,

1) 다른 멤버들(Peers)과 통신하기 위해 추가적인 peer's certificates가 필요하다.

2) 인증서가 만들어지면, etcd 서버가 시작될 때 그것들을 정의한다.

  - key, cert file option 및 여러 옵션이 있고,

클라이언트가 connect하는 서버가 유효한지 체크하기 위한 root certification이 있다.

kube-api server를 보자.

kube-api server의 경우, 매우 많은 연동포인트들과 요청을 받기 때문에 kube-api server외에도 k8s 등 다양한 이름을 가지고 있다. (외부에서 봤을 땐, kube-api server를 모르므로 k8s라는 이름을 갖고있는 것이다)

그리고 이런 이름들은 발급된 인증서에 반드시 명시가 되어 있어야 하는데, 그걸 openssl.cnf 파일의 [alt_name]에 명시한다.

그리고, api server가 클라이언트로서 etcd, kubelet과 통신할 때

이런 인증서들은 api server의 service configuration 파일 내에 정의되어야 한다.

1) --client-ca-file: its client를 증명하기 위해 필요 (모든 컴포넌트들이 필요함)

2) --tls-cert/private key: api server 인증서

3) --etcd / --kubelet 정의

kubelet server를 보자. 

여긴 이름을 어떻게 정의할까? kubelet이 아니라 각 node별로 정의한다.

kubelet의 client 또한 api server와 통신하기 위해 정의를 해야하는데,

api server는 어떤 노드가 인증되어 있는지, 적합한 퍼미션을 주는지 알아야 하기 때문에

이름 포맷이 제대로 정의되어야 한다.

node는 이전 apiserver, etcd들 처럼 시스템 컴포넌트이기 때문에 format은 system부터 시작한다.

그럼 api 서버는 어떻게 맞는 퍼미션을 줄까? 그룹네임을 이용한다. 

node 또한 system node라는 그룹 네임을 추가한다. 이건 뒤에서 더 알아본다.

출처: Udemy 사이트의 Certified Kubernetes Administrator (CKA) with Practice Tests 강의

SSL TLS 기본에 대한 강의다! (완전 친절)

1. TLS가 무엇일까?

위와 같이 예를 들어 보자. 사용자가 http://my-bank.com 서버로 개인정보를 이용하여 (1번) 로그인을 시도하면,

랜덤 숫자들(2번)을 통해 내 키가 'LKJSDFK: XZKJSDLF'로 암호화 된다(3번. encrypted).

그리고 그 암호화된 정보가 server로 전달된다.

* 그럼 중간에 해커가 정보를 가로채더라도, 암호화되어있기 때문에 해당 정보를 식별할 수 없다.

다만, 서버 또한 해당 key를 식별할 수 없다.

그래서, 랜덤 숫자 key까지 함께 보내줘서 decrypt하게 한다.

다만, 이렇게 될 경우 해커 또한 decrypt를 할 수 있다.

=> 이 방법이 Symmetric encryption 이다.

1. Symmetric encryption은

양단(encrypt, decrypt)에서 동일한 key를 사용하기 때문에 해킹이 가능하고,

key도 노출되기에 매번 바꾸어주어야 한다.

그래서 다른 방법을 알아보자.

2. Asymmetric Encryption

양단 간의 key를 'Private Key', 'Public Lock'로 분리했다.

Public Lock은 누구나 접근 가능하지만, 기 associated된 private key만 unlock을 할 수 있다.

예시를 한번 들어보자.

서버에 접근할 때, id/pw를 사용하고 싶지 않아 유저는 ssh-key를 generate한다.

#ssh-keygen

그럼 id_rsa 이라는 private key와 id_rsa.pub라는 public lock이 생성된다.

그런데, 유저들이 많아지면 어떻게 할까? (아래 핑크색 유저)

server에도 또 다른 문이(public lock) 또 생긴다.

서버 입장에서도 public lock을 생성해야 하므로 아래 커멘드를 사용하여 key를 만든다.

#openssl genrsa -o 

그럼, 유저가 https를 사용하여 web server에 처음 접근할 때, 서버로부터 public key를 얻는다.

근데 해커도 public key를 카피할 수는 있다.

그리고 유저는 해당 key를 이용하여 정보를 암호화하고, 이를 서버에 보낸다.

해커 또한 이 정보를 사용할 수 있겠다.

그러나, 해커는 키를 decrypt하고 symmetric key를 조회하기 위한 private key를 가지고 있지 않다.

즉, 해커는 only public key만 가지고 있는 것이다. 따라서, lock or encrypt만 가능하다.

receiver 서버는 동일한 key가 있기 때문에, 정보를 decrypt가능하다.

그럼 해커는 해킹할 방법이 없을까?

아니다. 있다.

해커가 은행 사이트와 동일한 웹 사이트를 만들고, 유저의 라우팅을 그 사이트로 가도록 우회시킨다.

그리고 public key를 가지고 있으니 유저가 값만 전달하면, 이를 decrypt할 수 있겠다.

그래서, 인증서라는 개념이 나온다.

그런데, 해커도 인증서를 만들 수 있지 않은가?

다행히 대부분의 web brower는 인증서의 validation을 체크할 수 있어서 이를 방지할 수 있다.

그럼, 어떻게 인증된 certificate (legitimate certificate)를 만들 수 있을까?

CA라는 공인된 organization에 CSR(Certificate Signing Request)을 통해 만들 수 있다.

# openssl req -new -key my-bank.key -out my-bank.csr

    -subj "/C=US/ST=CA/O=MyOrg, Inc./CN=my-bank.com"

해커의 인증서인 경우, 이는 CA의 Validate check에서 거절당한다.

근데, 또 fake CA를 사용하여 인증서를 만든다면?

괜찮다. 웹 브라우저에는 위 공인된 기관의 Certificate가 이미 등록되어 있기 때문에 fake CA를 가려낼 수 있다.

여기까지는 은행같은, 우리가 방문하는 웹사이트에 대해 확신을 줬다.

그런데, 이들은 pravately 하게 hosted되는 사이트에 대해서는 validate할 수 없다.

예를 들어, 연봉접근이나 내부 이메일을 통한 경우 말이다.

이를 위해 우리는 private CA를 가질 수 있다.

그럼 internal CA 서버를 통해 public key를 가질 수 있고, secure connetivity를 수립할 수 있다.

정리하자면, 위와 같은 1~6 절차를 통해 사이트 접근이 진행된다.

그런데, 서버는 어떻게 client를 validate할까?

위 절차로 진행한다.

그런데, 우리는 website에 접속하기 위해 client 인증서를 만든 적이 없다.

왜냐면, TLS client certificate는 일반적으로 웹서버에서 실행되기 때문이다.

그래서 인증서를 굳이 만들고 관리할 필요가 없다. 

즉, ca 및 생성, 인증서를 포함한 모든 절차는 public key 인프라스트럭쳐 or PKI라고 부른다.

네이밍은 위와 같다. PUBLIC는 *.crt, *.pem이고 private key는 *.key가 포함된다.

출처: Udemy 사이트의 Certified Kubernetes Administrator (CKA) with Practice Tests 강의

K8s에서는 Security가 매우 중요하다. 

kube-apiserver를 중심으로 security가 이뤄지는데, 중요한 것은

1. 누가 access할 수 있고

2. 그들이 뭘 할 수 있느냐다.

1. 누가 access할 수 있냐!? User 계정, 토큰, 인증서, ldap, service account 등이 있다.

2. 접근에 대해 권한을 받은 그들이 뭘 할 수 있냐면,

RBAC, ABAC, Node Authorization, Webhook Mode를 한다고 한다.

이게 뭘까? 하나씩 알아보자.

먼저, 각 컴포넌트들은 Kube ApiServer를 중심으로 TLS를 사용하여 보안을 유지하고 있고,

pod간은 network policy를 통해 보안을 유지하고 있다.

그럼, 먼저 내부 클러스터간 어떻게 인증을 해서 통신을 하고 관리되는지 알아보자.

먼저, cluster에 접근하는 user는 크게 Admin, Developers, Robots(k8s로 접근하는 외부 프로세스 들)으로 나눈다.

크게 보면 사람 / 로봇이다.

그런데, k8s는 자체적으로 user 관리를 하지 않고 Service Account에 한해 관리를 한다.

* Service account는 나중에 다루고, 이번 강의에선 user에 집중한다.

먼저 유저들은 API SERVER를 통해 K8S에 접근하는데, kube-apiserver가 해당 req에 대한 과정이 진행되기 전,

유저 인증(Authentication user)를 진행한다.

어떻게 인증을 할까?

StaticPassword File(직접 정보 입력), Static Token file, Certificates, Identity Service (3rd party authentication program. ex. LDAP)등의 방법이 있다.

1. StaticPassword File

user의 id/pw를 별도의 csv로 저장한 후, 그걸 apiservice.service에 '--basic-auth-file=user-details.csv'로 가져온다.

pod가 생성되면, curl 명령을 통해 kube-api server로 user의 id/pw를 이용하여 인증한다.

그리고, static password file에는 optional로 group 필드가 하나 더 있으며,

2. Static Token File은 Static password file 대비, password 대신 token을 사용한다.

key값 또한 '--basic-auth-file=user-details.csv'가 아닌, '--token-auth-file=user-details.csv'를 사용한다.

위에서 다룬 내용들은 이해를 위해 쉬운 방법들을 다룬 것이지, 권고하는 방법은 아니다.

다음 강의에서 하나씩 더 알아보자.

출처: Udemy 사이트의 Certified Kubernetes Administrator (CKA) with Practice Tests 강의

우린 이때까지 클러스터에 deployment, service definition file들을 이용하여 많은 app을 설치했다.

그 중에, etcd는 모든 클러스터와 관계있는 정보들이 저장되었는데,
만약 app이 persistent storage에 configured 된다면, 백업을 위한 다른 방법이 있다.

우리가 클러스터 내에 resource를 생성한다면, 명령어/YAML등을 통해 이를 정의했다.
그리고 후자의 방법(YAML을 통한 정의)이 더 선호되는 방식이다.

왜냐하면, object들은 하나의 폴더 내 object definition 형태를 요구하기 때문이다.

그래야 다음에 재 사용도 가능하고, 정보가 날라갔을 때도 얼른 붙여와서 사용할 수 있다.
그래서 이런 것들은 source code repository에 저장하는 것이 좋다. (GitHub등)
그리고 이런 repository는 적절한 backup solution이 설정되어야 하는데,
GitHub과 같은 repository는 이에 대해 걱정할 필요는 없다.

또 하나의 resource 설정 backup 방법은, kube-apiserver에 쿼리해서 모든 정보를 저장하는 것이다. 
# kubectl get all --all-namespaces -o yaml > all-deploy-services.yaml

그런데, 사실 이렇게 하는 것도 적은 resource에 대해서만 유용하지,

app이나 저장할 양이 커지면 관리하기도 어렵다.

그래서, k8s API를 사용하는 대용량 저장을 위한 VELERO라는 솔루션도 있다.

그럼 다시 ETCD Cluster로 돌아가본다.
etcd는 클러스터 자체, 그리고 내부 상태에 대한 정보를 저장한다. 

따라서, 이전과 같이 리소스를 백업하는 대신, 백업할 서버를 선택할 수 있다.  
etcd는 master node에 호스팅 되는데, etcd 내 모든 정보가 저장되는 location이 별도로 설정된다. (--data-dir=/var/lib/etcd/ )

그리고, etcd에는 snapshot 이라는 내장 기능도 있다.

ETCDCTL_API=3 etcdctl \
   snapshot save snapshot.db

그럼 복구 기능은?
kubeapi server를 stop시킨다. 그런 다음 etcdctl를 통해 snapshot restore + path cmd를 사용한다.
그러면, etcd는 backup파일로부터 복구를 시작하고, etcd 멤버가 새 멤버인 것처럼 새 클러스터에 설정된다(?).

이 방법은 존재하는 클러스터로부터 뉴 멤버를 막기 위함이다.(??? 이해 못함)

이렇게 하면, 새 데이터 디렉토리가 생성되고, 생성된 새 directory를 etcd config파일에 설정한다.
이후에 service 데몬을 reload하고 restart etcd를 한다.
k8s api server가 시작되면, 클러스터는 오리지널 상태가 된다.


정리하자면, 백업을 위한 2가지 옵션이 있다.
1. backup using etcd
2. backup using by querying the kube-APIverver
만약 cloud등의 환경에서 k8s를 사용한다면, outside cluster를 향한 접근이 없으니 2번을 쓰는 게 편할 것이다. 

# ETCDCTL_API=3 etcdctl version
# ETCDCTL_API=3 etcdctl --cacert="" --cert="" --key="" snapshot save /opt/snapshot-pre-boot.db 
 // 위의 ""에 kubectl describe po를 통해 조회한 값을 넣는다.

status도 조회 가능하다.

# ETCDCTL_API=3 etcdctl snapshot status /opt/snapshot-pre-boot.db 

복구

# ETCDCTL_API=3 etcdctl snapshot restart <filename> --data-dir= 
  ex. ETCDCTL_API=3 etcdctl snapshot restart /opt/snapshot-pre-book.db --data-dir=/var/lib/etcd-backup
  // 이렇게 하면 etcd-backup 디렉토리가 생성되고, restore도 진행됨.
  data-dir은 etcd yaml 파일에 있기 때문에, hostPath도 backup으로 인해 생성된 backup directory로 바꿔주기.

출처: Udemy 사이트의 Certified Kubernetes Administrator (CKA) with Practice Tests 강의

K8s에는 각 컴포넌트마다 다른 버전을 가지고 있다.

그런데, kube-apiserver가 가장 상위 버전이고, 다른 것들은 kube-apiserver보다 높은 버전을 가질 수 없다. (동일은 가능)

단, kubectl의 경우 상위버전, 동일버전, 하위버전 모두 가질 수 있다.

그리고, k8s는 하위 3개의 minor버전까지만 support하기 때문에, v1.13이 배포되었다는 기준으로 

v.11까지만 upgrade할 수 있다.

그리고, upgrade를 할 땐 v1.10 -> v1.13으로 바로 가지말고, minor버전을 하나씩 올리라고 권고하고 있다.

ex. v1.10 -> v1.11 -> v1.12 -> v1.13

그럼, upgrade는 어떻게 진행할까?

GCP등 ServiceProvider에 올린 경우 버튼 몇번으로 진행할 수 있고,

이 외는 kubeadm을 통해 진행할 수 있다.

upgrade 절차는 Master Node를 먼저 진행하고, 그 이후엔 3가지 전략이 있다.

1) 전체Node 삭제 후 전체 Node 생성: service impacted

2) 하나의 Node씩 Upgrade: Impact 없음

3) 최신 버전인 new Node를 하나 생성한 후, 기존 node를 하나씩 upgrade하고, 기존 node중 하나 삭제

 (3은 cloud 환경에 있다면 가장 쉽고 편한 방법)

실제 upgrade command는

1. kubeadm upgrade plan을 통해 available한 pkg version을 조회한다.

# kubeadm upgrade plan

1 apt-get을 통해 pkg를 땡겨오고 (available한 건 v1.13.4였지만, 버전이 v1.11.3이었으므로 하나씩 올린다)

2. kubeadm upgrade apply v1.12.0을 통해 pkg를 upgrade한다.

3. version을 조회하면 아직 v1.11.3이다.

4. 이유는, 해당 버전은 kubelet을 기준으로 보이는데, kubelet이 upgrade되지 않았기 때문이다.

   그래서 kubelet을 마지막으로 upgrade한다.

# apt get upgrade -y kubeadm=1.12.0-00
# kubeadm upgrade apply v1.12.0
# kubectl get nodes
# apt-get upgrade -y kubelet=1.12.0-00
# systemctl restart kubelet

각 Node들을 upgrade할 땐, 이전 포스팅에서 다루었던 drain, uncordon 명령을 통해

https://countrymouse.tistory.com/entry/cka-6-1

node에 있는 pod가 미리 다른 pod로 옮겨갈 수 있게 설정해준다.

출처: Udemy 사이트의 Certified Kubernetes Administrator (CKA) with Practice Tests 강의

pod를 upgrade할 때, pod들은 자동으로 down 되었다가 up이 된다.

그런데 이때, default 타이머가 5분으로, k8s는 5분동안 pod가 살아나지 않으면 죽었다고 판단 후 다른 node에 pod를 생성한다.

그럼, Node가 down될 경우는 어떨까?

(지금은 아무것도 없는) 2번째 Node에 파랑, 초록 pod들이 있었다.

그런데, Node 2가 down되면, replica에 속한 파란 노드의 경우 다른 node에 생성될 수 있다.

그런데, 초록이는 혼자 있던 pod(=daemon set)이고 replicaset에 속하지 않았기 때문에 다른 node로 생성될 수 없다.

그런데, 그림 상에는 왜 초록색pod가 4번째 pod에 있냐면,

# kubectl drain node-2

위 drain command를 통해, Node-2에 속한 pod들을 다른 Node로 이동시킨 것이다.

* drain: 해당Node에서 실행 중인 pod들을 다른 곳으로 이동시키는 명령어

직접 수행해보자.

$ kubectl get nodes
NAME                 STATUS    ROLES     AGE       VERSION
docker-for-desktop   Ready     master    4d        v1.10.3


$ kubectl drain docker-for-desktopnode
"docker-for-desktop" cordonederror: unable to drain node "docker-for-desktop", aborting command...There are pending nodes to be drained:docker-for-desktoperror: DaemonSet-managed pods (use --ignore-daemonsets to ignore): kube-proxy-4s52d
우선 kubectl drain을 해보면 다음처럼 에러가 납니다. 데몬셋으로 떠 있는 포드가 존재하기 때문입니다.
// DaemonSet의 경우 drain을 사용할 경우 반드시 아래 옵션을 줘야한다.


** --ignore-daemonsets=true 옵션을 주고 다시 실행하면 정상적으로 실행되는걸 확인할 수 있습니다.
$ kubectl drain docker-for-desktop --ignore-daemonsets=true
node "docker-for-desktop" already cordonedWARNING: Ignoring DaemonSet-managed pods: kube-proxy-4s52dpod "compose-api-6fbc44c575-k6fz8" evictedpod "compose-7447646cf5-w4mzb" evictedpod "kubernetes-simple-app-57585656fc-nvkxm" evictedpod "kube-dns-86f4d74b45-dt5rb" evictednode "docker-for-desktop" drained

출처: 
https://arisu1000.tistory.com/27845 [아리수]

그럼 cordon 명령어는 뭘까?

* cordon: 해당 노드에 더이상 pod들이 scheduling되지 않게 하는 것(존재하던 pod는 유지)

$ kubectl get nodes
NAME                 STATUS    ROLES     AGE       VERSION
docker-for-desktop   Ready     master    4d        v1.10.3

 

$ kubectl cordon docker-for-desktop

node "docker-for-desktop" cordoned

 

$ kubectl get nodes

NAME                 STATUS                     ROLES     AGE       VERSION

docker-for-desktop   Ready,SchedulingDisabled   master    4d        v1.10.3

$  kubectl uncordon docker-for-desktop// scheduling되게 다시 변경

그럼 새로운 pod가 생성될 때, 해당 node에는 scheduling이 되지 않는다.

그리고, cordon 속성을 제거하거나 / drain 속성을 풀려면 'uncordon'을 수행하면 된다.

$  kubectl uncordon docker-for-desktop// scheduling되게 다시 변경

출처: https://arisu1000.tistory.com/27845 [아리수]
출처: Udemy 사이트의 Certified Kubernetes Administrator (CKA) with Practice Tests 강의

위와 같이 pod에 특정 환경변수를 설정하려면 어떻게 하는게 편할까?

pod definition YAML에 설정할 수 있다.

하지만, pod definition file이 많다면 query files 내에 저장된 environment data 관리에 어려움이 있다.
그래서, 이 configuration들을 묶어 pod-definition 파일 밖에서 ConfigMap과 Secrets 파일을 만든다.

1. ConfigMap: 일반적인 plain text를 별도의 파일에 저장. 
  pod가 생성될 때, ConfigMap이 pod 내부로 추가되고, 해당 파일에 있는 환경 변수들을 사용할 수 있다.

 1) ConfigMap의 두 가지 phase

   (1) Create ConfigMaps
      -  imperative way (command로 생성. file 미작성)

         . kubectl create configmap 명령어

# kubectl create configmap <config-name> --from-literal=<key>=<value>
ex. app-config --from-literal=APP_COLOR=blu
                   --from-literal=APP_MOD=prod  (추가로 원하는 속성이 있다면)

    - Declarative way (file 작성)

      . kubectl create -f  [file Name]
       ex. config-map.yaml 생성

   (2) Inject them into the POD (다른 object들 처럼)
    - (ENV의 경우) "envFrom:" key 추가 
    envFrom:
      - configMapRef:
            name: app-config // 여기에 configmap의 name 넣기

 - (Single Env의 경우) valueFrom:
 - (Volume의 경우) configMap:

  * ConfigMap 조회

2. Kubernetes Secrets

위에서 ConfigMap을 알아봤는데, ConfigMap은 모든 data를 plain 형태로 저장했다.

그런데, id/pw와 같이 민감한 값을 저장해야 한다면 configMap이 적합할까?

당연히 아니다.

그래서, 이런 민감한 정보들은 Screts 파일에 암호화하여 저장한다.

Secrets 역시 2가지 Phase로 나눠진다.

1) CREATE Secret
2) Inject them into the POD 

하나씩 알아보자.

먼저 이 역시 명령형(imperative)와 선언형(Declarative)로 나뉜다.

먼저 명령형 부터.

# kubectl create secret generic <secret-name> --from-literal=<key>=<value>
ex. kubectl create secret generic \
       app-secret --from-literal=DB_Host=mysql app-secret
                      --from-literal=DB_User=root ...

설정이 많아지면, file로 가져오는 명령어도 있다.
# kubectl create secret generic <secret-name> --from-file=<path-to-file>
ex. kubectl create secret generic \ app-secret --from-file=app_secret.properties

다음은 역시, 선언형이다.

kubectl create -f secret-data.yaml
 * 단, secret은 민감한 정보를 다루기 때문에, plain text말고 encoded된 형식으로 "직접" 작성해야함.

어떻게 encoded된 형식으로 변환?   'echo -n' 명령어 사용!

# echo -n 'mysql' | base64 
# echo -n 'root' | base64 

그럼 decode 방법은!?

#'echo -n 'bXlzcWw=' | base64 --decode 

2) Inject them into the POD 
 ConfigMap과 동일하게 아래와 같은 key를 추가한다

- (ENV의 경우) "envFrom:" key 추가 
    envFrom:
      - secretRef:
            name: app-config // 여기에 configmap 이름 넣기

 - (Single Env의 경우) valueFrom: secretKeyRef:
 - (Volume의 경우) secretName:

위는 정말 secret파일이 container에 포함되는지 확인하는 명령.

* Note)
# explain kubectl explain [--recursive=false] [flags]
파드, 노드, 서비스 등의 다양한 리소스에 대한 문서를 출력한다.
출처: https://kubernetes.io/ko/docs/reference/kubectl/overview/

controller-0:~$ kubectl explain pods --recursive | grep Volume -A3

출처: Udemy 사이트의 Certified Kubernetes Administrator (CKA) with Practice Tests 강의

컨테이너는 OS를 점유하지 않고 특정한 task나 process를(ex.webserver, app server, db) 실행하기 때문에,
task가 완료되면 컨테이너는 exit 된다. 

즉, 컨테이너는 프로세스가 동작중일 때만 살아있는다.
예를 들어, 컨테이너 내부의 web server가 중지되거나 crash되면, 컨테이너도 종료된다. 
(위 그림을 보면, ubuntu를 run했으나 곧내 Exit 된걸 볼 수 있다)

그럼, 컨테이너 내에서 어떤 프로세스가 구동될지는 누가 정의할까?

docker file을 보면(여기서는 nginx), 'CMD'(=command)라는 instruction을 볼 수 있다.
즉, 해당 프로그램이 컨테이너가 시작되면, 컨테이너 내에서 구동될 것이라는 것을 의미한다. 
mysql에는 mysqld가 있다.

Ubuntu 파일의 docker file도 보면, 'bash' 라는 default cmd가 있다.
그런데, bash는 webserver와 db와 같은 프로세스가 아니라 쉘이다.
* shell: 터미널로부터 input을 listen. 없으면 종료.

우리가 우분투 컨테이너를 생성할 때,

docker는 우분투 img로부터 container를 생성하고, bash program을 구동한다.
그런데, 기본적으로 docker는 터미널이 포함되어 있지 않기 때문에,

bash program은 터미널을 찾을 수 없고, 이내 프로세스는 시작되자마자 종료될 것이다. 

1. 'docker run' command 

: 컨테이너가 생성되자마자 종료되지 않기 위해서는 어떻게 해야할까?

sleep 5초를 줘보자.
# docker run ubuntu sleep 5 // ubuntu 컨테이너를 시작할 때, sleep program을 함께 구동, 5초간 기다렸다가 exit

* 그런데 이것은 일시적인데... 어떻게 영구적으로 적용할까?
새 커멘드를 만들면 된다.

docker build -t ubuntu-sleeper
docker run ubuntu-sleeper

단, CMD에는 항상 키와 값을 따로따로 써줘야 한다.

ex. ["sleep", "5"]  // ["sleep 5"]하면 안됨

그럼 value(값)를 바꾸고 싶다면?
ENTRYPOINT로 명령어를 수행하고, CMD를 통해 매개변수 값을 입력한다.

런타임에 ENTRYPOINT를 sleep2.0으로 수정하고 싶다면? 
entry point option을 사용해서 override할 수 있음.
 # docker run --entrypoint sleep2.0 ubuntu-sleeper 10

그럼 위의 설정은 YAML에 어떻게 입력 할까?
args:가 CMD에 있는 매개변수 값으로, args에 value를 입력해준다.
그리고 ENTRYPOINT가 command: 이다. (Entrypoint를 수정하고 싶다면, YAML에 위와 같이 "sleep2.0"으로 바꿔도 된다)

출처: Udemy 사이트의 Certified Kubernetes Administrator (CKA) with Practice Tests 강의