version을 보기 위해서는 왼쪽과 같이 조회할 수 있고, pod의 lists들을 얻기 위해서는 오른쪽과 같이 조회할 수도 있다.
여기서 말하는 /version, /api 들이 API Group이다.
실제로 api group들은 위와 같이 다양한데, 클러스터 functionality와 관련있는 /api, /apis에 대해 알아본다.
/api는 core server이고 /apis는 named server인데 아래에서 하나씩 알아보자.
core group인 /api는 all core functionality가 존재하는 곳으로 namespace, pods, nodes들이 정의되어 있다.
named group인 /apis는 더 정교한 정보들이 저장되어 있고, new feature들이 available 해진다.
크게 API Groups으로 나누고, 그 아래에서 Resource, Verbs 등으로 한 번 더 나뉜다.
All resources in Kubernetes are grouped into different api groups. At the top level you have core api group and named api group. Under the named api group You have one for each section under this API group.
You have the different resources and each resource has a set of associated actions known as verbs in
the next section on authorization.
실제로 k8s에서 해당 api group들을 조회해본다.
# curl http://localhost:6443 -k // available한 api group listup
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 강의
인증서에 문제가 있을 때(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 강의
우린 이때까지 클러스터에 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 강의
