시골쥐의 공부생활

강의가 거의 끝나고, Troubleshooting 섹션이 시작됐다.

크게 아래와 같이 4개의 Failure를 다루는데 하나씩 정리해보겠다.

- Application Failure

- Worker Node Failure

- Control Plain Failure

- Networking

1. Application Failure

먼저, 문제가 발생했을 경우엔 오른쪽과 같이 architecture를 알아야 한다.

어떤 pod와 어떤 service로 구성되어 있는지 말이다. 

그래서 FrontEnd부터 (그림에서는 WEB-Service) 천천히 내려가보는 것이다.

그래서 왼쪽과 같이 curl http://web-service.ip:node-port를 를 통해 해당 service가 문제없는지 확인해볼 수 있고,

이후엔 describe를 통해 web-service의 상태 및 config값을 조회할 수 있다.

여기서는 web pod와 연결되기 위해 Selector가 초록으로 마킹되어 있는데, 이게 pod와 맞는지 확인하는 것도 잊지 말아야한다.

서비스에 이상이 없다면, 이제 pod로 넘어간다.

kubectl get pod를 통해 pod상태를 조회하고, describe로 상세 상태를 보고, logs를 통해서도 문제를 확인할 수 있다.

여기서 -f, --previous 옵션을 붙이면 이전 pod의 상태에 대해서도 확인할 수 있다.

#kubectl logs [pod] -f --previous

여기서도 문제가 없다면, 이제 DB-Service / DB로 내려간다.

이론 설명 후 Practice 강의가 있었는데 대부분은 Selector, DB ID/PW(Root pw까지도), NodePort, Target Endpoint port error(Target Port), ep(endpoint) 문제이다.

ep는 여기서 처음 들어봤는데 # kubectl get po -n [namespace] ep를 통해 조회할 수 있고,

service가 selector를 통해 쳐다보고 있는 Endpoint(pod)를 보여준다. 

2. Control Plain Failure

1) Node, pods상태, kube-system에 속한 controlplain pods상태를 확인한다.

  # kubectl get nodes 

  # kubectl get pods

  # kubectl get pods -n kube-system

만약 Controlplain 컴포넌트들이 service 형태라면, service를 위와 같이 조회할 수 있다.

# service kube-apiserver status

# service kube-controller-manager status

# service kube-scheduler status

service logs를 통해서도 문제를 확인 가능하다.

kube-apiserver의 경우 journalctl를 사용한다.

# kubectl log kube-apiserver-master -n kube-system

# sudo journalctl -u kube-apiserver

Practice test에서는 아래와 같은 내용을 다룬다.

1) pod 한 개가 pending 상태. 근데 pod엔 문제가 없어보임.

 -> scheduler issue일 수 있음.

# kubectl get po -n kube-system

  // 를 통해 scheduler가 Crashloopbackoff 상태인 것을 확인.

그래서, scheduler를 describe하여 조회한 결과, 'failed to start container "kube-scheduler": Error response from daemon: OCI runtime create failed: container_linux.go:345: starting containre process caused "Exec: \"kube-schedulerrrr\": executable file not found in $PATH: unknown" error가 존재하였음.

=> kube-scheduler-master yaml파일에 가서 수정한다. 

# cat /etc/systemd/system/kubelet.service.d/10-kubeadm.conf   

   // kubectl config.yaml 경로 조회 가능 (/var/lib/kubelet/config.yaml)

# grep -i staticPodPath /var/lib/kubelet/config.yaml

  : staticPodPath: /etc/kubernetes/manifest // default path

# cd /etc/kubernets/manifests/

# vi kube/scheduler.yaml

 여기서 spec: containers:의 command에 'kube-schedulerrrr'가 있다. 이걸 정상 값(kube-scheduler)으로 수정해준다.

2) deployment를 통해 pod를 2개로 scale 

 # kubectl scale deployment app --replicas=2 // 그런데 scale이 되지 않음! 그래서 tshoot 진행.

 # kubelet get pods -n kube-system // replica를 담당하는 kubec-controller-manager이 역시나 Crashloopbackoff 상태.

 # kubectl -n kube-system describe kube-controller-manager 조회 // 문제 없음

 # kubectl -n kube-system logs kube-controller-manager-master 

  // 'stat /etc/kubernetes/controller-manager-xxxx.conf: no such file or directory' 출력

# cd /etc/kubernetes 가보니 controller-manager 파일이 있음. (-xxxx.conf 가 아님)

 # vi /etc/kubernetes/manifests/kube-controller-manager.yaml 파일 조회

  // spec: containers: command에 있는 kueconfig=/etc/kuberenets/controller-manager-xxxx.conf 파일 수정

이후 deployment 및 controller가 정상 동작되고 replica도 정상 동작하는 것을 확인했다.

3) controller-manager의 re-broken

 # kubectl get pods -n kube-system // kube-controller-manager-matser = Crashloopbackoff

 # kubectl describe po kube-controller-manager-master -n kube-system // 이슈 없어보임

 # kubectl logs kube-controller-manager-matser -n kube-sysetm 

  // 'unable to load client CA file: unable to load client CA file: open /etc/kuberenetes/pki/ca.crt: no such file or directory' 라는 에러 존재

# vi /etc/kubernetes/manifest/kube-controller-manager.yaml 확인 

  // ca.crt를 쓰고 있는 부분 확인. mountpath가 /etc/kubernetes/pki를 가지고 있는 것의 name이 'k8s-certs'임.

이걸로 다시 파일 내 조회. 그리고 그것들의 path 확인. WRONG-PKI-DIRECTORY가 있음.

 # cd /etc/kubernetes/WRONG-PKI-DIRECTORY/ 

  // 직접 해당 디렉토리 내 ca.crt가 있는지 확인. 그런데 파일이 없음.

 # cd /etc/kubernetes/pki/

  // 여기에 key값들 있는 걸 확인

# vi /etc/kubernetes/manifest/kube-controller-manager.yaml 확인 

  // k8s-cert를 쓰고 있는 path를 확인. hostPath가 /etc/kubernetes/WRONG-PKI-DIRECTORY로 설정되어 있음.

     이걸 /etc/kubernetes/pki로 변경

3. Worker Node Failure

Worker node가 문제있을 땐 node 상태 및 kubelet, Certificates (만료 여부 등)를 확인해볼 필요가 있다. 

- Practice에서는 kubelet과 kube-proxy에 대해 다룬다.

1. node 01 Not ready  with kubelet

1) kubelet get nodes를 조회했더니, node01이 Not Ready 상태이다.

2) ssh node01로 들어간다.

3) ps -ef | grep kubelet  // kubelet이 running중이 아니었다.

4) systemctl status kubelet.service // inactive 확인

5) systemctl restart kubelet // active가 되었다.

6) kubelet get nodes // node01이 ready 상태로 변했다.

2. Node 01 Not Ready with kubelet

1) kubelet get node // node01 = not ready

2) kubectl describe node node01 // 별다른 게 없다.

3) ssh node01

4) sytsemctl status kubelet.service -l // activating 상태

5) journalctl -u kubelet // kube-proxy log 조회

  'open /etc/kubernetes/pki/WRONG-CA-FILE.crt: no such file or directory 확인

6) cd /etc/systemd/system/kubelet.service.d/    // kubelet config 조회. 10-kubeadm.conf가 존재

7) cat 10-kubeadm.conf // Environment=KUBELET_CONFIG_ARGS 및 KUBELET_KUBECONFIG_ARGS 존재

 // KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml 조회

8) vi /var/lib/kubelet/config.yaml

9) /pki/WRONG-CA-FILE.crt 존재, 이부분 수정

10) cd /etc/kubernetes/

11) ls 조회 시 pki/ 및 kubelet.conf뿐.

pki/에 들어가보니 ca.crt가 있음. 즉, 경로는 /etc/kubernetes/pki/ca.crt가 되어야 함.

12) vi /var/lib/kubelet/config.yaml에서 /etc/kubernetes/pki/WRONG-CA-FILE.crt -> /etc/kubernetes/pki/ca.crt로 변경

13) systemctl daemon-reload

14) systemctl restart kubelet

15) kubelet은 active상태가 되었고 node는 ready 상태가 되었다.

3.  Node01 Not Ready with kubelet

1) kubelet describe node node01 // 도움되는 정보 없음

2) ssh node01

3) sytsemctl status kubelet // active & running, but error exist

  'dial tcp 172.17.0.22:6553: connect: conenction refused'

4) journalctl -u kubelet // kube-proxy log 조회, 동일한 err 존재

5) kubelet cluster-info // master node에서 master ip 및 port 확인 (172.17.0.22:6443)

6) ssh node01 

7) cd /etc/systemd/system/kubelet.service.d/    // kubelet config 조회. 10-kubeadm.conf가 존재

8) cat 10-kubeadm.conf // kubeconfig=/etc/kubernetes/kubelet.conf 확인

9) vi /etc/kubernetes/kubelet.conf // server section에서 port 변경 ( 6553-> 6443) 

10) system daemon-reload

11) system restart kubelet

12) kubelet은 active 및 error가 존재하지 않으며 node또한 ready 상태가 됨.

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

웹 페이지를 개설했다면, 그리고 외부에서 접근가능하려면 어떻게 해야할까?

이를 위해 많은 분들이 Service와 Ingress를 혼동한다. 그래서 이에 대해 짧게 알아보도록 하자.

NodePort type의 Service를 통해 포트를 정의해줘서 외부로부터 접근이 가능하게 만들 수 있다.

그리고, 포트를 외우기 귀찮으니(원래는 http://my-online-store.com:38080으로로 접근)

proxy server를 이용함으로써 URL을 통해 접근 가능하게 한다.

만약 GCP등의 Cloud platform을 사용한다면 LoadBalancer Type의 service를 사용하면 된다.

그럼 K8s가 알아서 포트, 외부 ip등을 다 할당해준다.

자, 그런데 비즈니스가 잘 되어서 /watch라는 또 다른 app을 만든다고 치자.

그럼 기존 my-online-store.com은 my-online-store.com/wear로 바꾸어야할 것이다.

그럼 동일한 클러스터 내 오른쪽 노란색 표기와 같이 새로운 인스턴스들을 만든다.

그럼, wear app에 접근 또는 video 앱에 각각 접근하기 위해 어떻게 해야할까?

가장 상단에 새로운 service를 만들어서 이 두개 app에 대한 정의를 해야하고, SSL enable도 시켜야 한다.

그런데 이건, app level과 다른 level이다.

그런데, app이 더 늘어날 경우?

계속 파일을 수정해줘야하고 SSL도 처리해야하고, 경로와 포트등을 계속 만들어줘야 한다.

그래서 Ingress라는 개념이 나왔다.

Ingress는 K8s에 built-in된 7계층 LoadBalancer로,

하나의 외부 URL을 이용해서 클러스터 내 다른 서비스로 라우팅을 시켜줄 수 있고, SSL Security또한 실행해줄 수 있다.

하지만, 이 또한 외부에서 클러스터로 접근하기 위해

node port 또는 cloud native LB를 사용해서 외부로 노출시켜줘야 한다.

다만, 이건 단 한번만 하면 된다. 

1. Deploy = Ingress controller

Ingress를 위한 solution으로는 nginx, haproxy, traefik 등을 사용하면 된다.

이렇게 deploy하게되는 솔루션들을 ingress controller라고 부르고,

2. Configure = Ingress resources

설정하는 rule들을 ingress resource라고 부른다.

이건 기존 우리가 생성했던 pod deploy처럼 definition file을 이용해서 생성된다.

그런데, ingress controller는 defualt로 built-in 되어있지 않다. 

그래서 이걸 무조건 deploy 해줘야 하는데, 어떤 걸 deploy 해줘야할까?

위와 같이 많은 종류의 사용 가능한 솔루션이 있다.

이 강의에서는 nginx를 예시로 사용하고 있고, 이건 기존에 사용하던 LB나 nginx 서버와는 다르다.

Ingress controller에서 LB 컴포넌트는 단지 일부일뿐이고, K8s 클러스터를 모니터링 할 수 있는 기능이 포함되어 있다.

Controller는 다른 deployment와 동일한 방식으로 deploy 되는데, definition file을 한번 확인해보자.

nginx program은 /nginx-ingress-controller라는 경로에 저장되어 있는데, 

keep-alive threshold, ssl setting, session timeout 등을 설정하기 위해 별도의 ConfigMap을 만든다.

그래서 configmap에 대한 정의 또한 args에 포함한다.

그리고, pod와 pod의 namespace 또한 env로 포함해줘야하고,

ingress controller에 의해 사용되는 ports 또한 추가한다.

그리고, ingress controller를 외부 세상에 노출하기 위해 service가 필요하다.

그래서 NodePort 타입의 service를 생성하고, label-selector를 이용해서 deployment와 링크시킨다.

그리고, 아까 언급했듯 ingress는 k8s 클러스터를 모니터링하는 추가적인 기능들을 갖고 있다.

그래서 어떤 설정이 변경되었을 때, 그것들을 nginx 서버에 설정할 수 있는데, 이를 위해 service account가 필요하다.

이 service account에는 맞는 퍼미션이 필요한데, 그를 위해 roles과 roles binding이 필요하다.

즉, 정리하자면

ingress를 위해서는 최소한으로 Deployment file, service file, configmap, Auth(ServiceAccount)가 필요하다.

ingress resource는 ingress controller에 적용되는 rules과 configurations들의 세트인데, 

첫 번째 그림과 같이 모든 incomming traffic에 대해 single application으로 route할 수도 있고, 

두 번째 그림과 같이 URL을 기반으로 다른 app들로 라우팅을 분배할 수도 있다. 

그럼 이것들을 어떻게 설정하는지 알아보자.

ingress resource는 위의 오른쪽과 같이 파일을 정의해주는데, pod에게 direct로 가는 게 아니라, service로 보내준다.

그리고, 다른 조건에 따라 traffic을 분리하고 싶을 때 rules을 사용할 수도 있는데,

위와 같이 www.my-online-store.com // www.wear.my-online-store.com/ 등으로 분리할 수 있다.

아래에서 하나씩 설정을 확인해보자.

위와 같이, 각 호스트의 top level로부터 rule을 생성할 수도 있고,

URL을 기반으로 라우팅 패스를 다르게 설정할 수도 있다. 

어떻게 설정할까?

처음엔 Ingress-wear.yaml를 사용했지만,

지금은 두 개의 app으로 나뉘므로, ingress-wear-watch.yaml 파일에서 각각의 path와 service를 정의해줘야 한다. 

이후 yaml파일을 apply로 생성하면, 위와 같이 ingress를 조회해볼 수 있다.

2가지 path가 생긴 것을 확인할 수 있는데, 위의 Default backend는 무엇일까?

유저가 접근을 시도하는 URL이 없을 때(어떤 Rule도 match되지 않을 때) 보여주는 page를 정의하는 것이다.

위의 oops 404 페이지처럼 말이다.

자, 그럼 3번째 설정 타입으로는 domain name 또는 host name을 이용하는 것을 알아보자.

이전 설정에선 host를 정의하지 않았는데, host를 정의하지 않으면

hostname matching 없이 특정 rule에 따라 incoming traffic이 허용된다.

이전에 만든 것과 비교해보면(왼쪽), rule에 hostname이 추가되었을 뿐이다. (오른쪽)

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

pod/container가 생성된 후, 그 안에 있는 data는 pod/container가 삭제되면 함께 삭제된다.

그래서, 이런 데이터들을 영구적으로 보관하기 위해 Volume이라는 개념이 나온다.

single node라면 위와 같이 pod-definition에 'volumemount', 'volumes'로

node 내에 있는 /data directory에 저장한다고 정의할 수 있다.

그런데, multi-Node가 된다면 이 방법은 점점 더 복잡해질 것이다.

그래서 AWS, cephFS와 같은 Storage를 사용한다.

PV, PVC를 알아보자.

위와같이 POD별로 각 Storage를 설정하면 복잡해지고, 하나가 수정될 때마다 전체를 수정시켜야하는 귀찮음이 있다.

그래서 이를 중앙에서 관리하기 위한 solution으로 PV라는 Volume이 나온다.

PV: storage volumes의 wide pool

A persistent volume is a cluster wide pool of storage volumes configured by an administrator to be used

by users deploying applications on the Cluster.

PVC: User가 pv를 할당받기 위해 생성하는 instance

The users can now select storage from this pool using persistent volume claims.

administrator는 PV를 생성하고, user는 PV를 사용하기 위해 PVC를 생성한다.

PV를 생성해보자. 

간단하다, 위와 같이 Yaml 파일을 작성한다.

그러면 PV와 PVC간 Binding 작업이 이루어지는데, 보통 capa, access mode등이 거의 유사한 것끼리 1:1 binding이 된다.

혹시 특정한 PV, PVC를 쓰고 싶다면 labels/selector를 통해 설정할 수 있다.

만약 pvc에 맞는 pv가 없으면, pvc는 pending 상태가 된다.

pvc를 생성해보자.

pv와 거의 동일하며 storage size를 맞춰주자.

그리고 pvc를 삭제할 수도 있는데, pvc가 삭제되었을 때 PV가 어떻게 될지 설정할 수도 있다.

- Retain (admin이 수동으로 삭제할 때까지 갖고있기), Delete(삭제됨과 동시에 삭제), Recycle(다른데서 사용)

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

모든 pod끼리는 서로 연결이 되어있다.

그런데, 일부 구간(ex. web Pod - DB Pod)은 direct로 연결되지 않길 바랄 수도 있다. (security 이슈 등으로 인해)

그럴 때, Network Policy 라는 것을 사용한다.

Ingress traffic을 3306, API Pod에게만 받는 것이다.

이때, 예전에 배웠던 Selector, labels 인스턴스가 다시 나온다.

NetworkPolicy라는 yaml파일을 만든 뒤, spec 아래 부분에 오른쪽의 두 블럭을 붙여준다.

예를 들어 이렇게.

spec:

  podselector:

    matchlabels:

      role: db

  policyTypes:

  - Ingress

  Ingress:

  - from:

    - podSelector:

        matchLabels:

          name: api-pod

  ports:

  - protocol: TCP

    port: 3306

그럼 조금 더 조건을 추가해보자.

pod는 api-pod 에서만 들어오도록 하고, namespace는 prod에 있는 것만,

ip는 192.168.5.10/32로부터 오는 것만 허용하도록 하자.

이 경우, '-'를 사용할 경우, 별개의 룰이 되어 &&조건이 아닌 || 조건이 된다.

따라서, api pod이거나, prod namespace 안에 있거나, 192.168.5.10/32로부터 오면 허용한다는 뜻이다.

만약 &&조건을 주고 싶으면, '-'를 없애면 된다.

그리고, egress도 동시에 추가할 수 있다.

egress도 engress와 동일하되, egress는 outgoing 하는 traffic이므로 'to' 옵션을 사용한다.

network policy에 대한 조회는 아래 커멘드로 확인할 수 있다.

# kubectl get netpol [policy name]

# kubectl describe networkpol [policy name]

끝-

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

이전 강의까지, 우리는 user에 대한 role binding을 알아보았고, namespace도 지정했다.

즉, role binding은 namespace 내에 생성된다.(만약 namespace가 명시되지 않았다면 default namespace 내에 생성)

그런데, Node는 namespace에 종속될 수 있을까?

아니다. 즉, resources들은 namespaced or cluster scope으로 구분된다.

그래서 이번 강의에서는 cluster role / cluster binding에 대해 알아본다.

cluster scope에서는 namespaced에서 정의되어 있지 않은 것들을 정의한다.

그 중에, user에서 권한을 주기위해 사용했던 roles, rolebindings 파일은, 

cluster scope에서 clusterroles, clusterrolebindings 파일이 된다.

cluster role/binding은 기존 namespaced가 특정 namespaced에 속한 resource만 관리된 것과 달리,

여러 cluster내에 걸쳐있는 namespace또한 관리할 수 있다.

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

RBAC에서 Role은 어떻게 만들까?

오른쪽 yaml파일과 같이 Role에 대한 yaml파일을 만들고, kubectl create로 role을 생성해주면 된다.

rules에는 여러개의 key가 들어가서 여러 조건을 줄 수 있고, apiGroups은 coregroup일 경우 비워둔다.

role YAML을 다 작성하고 나서는? user - role간 link를 해준다.

즉, user를 role object와 linkg해주는 Role-binding이라는 yaml을 만든다.

(위 그림에서는 devuser-developer-binding.yaml)

subjects는 user에 대한 details를 작성하는 곳이고, roleRef는 생성된 role에 대한 정보를 작성하는 곳이다.

그리고 kubectl create -f devuser-developer-binding.yaml을 통해 binding object도 실행해준다.

role과 rolebinding간 namespace를 동일하게 맞추는 것 잊지말자.

role, rolebinding을 조회하는 명령어.

내 권한이 특정 resource에 접근 가능한지 확인하는 방법이다.

#kubectl auth can-i [ ]

resourcename에 대한 권한도 rules 아래에 줄 수 있다.

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

Authorization이 왜 필요할까?

클러스터는 다양한 clients들이 함께 사용하는데, 각자의 권한에 따라 기능을 제한하기 위함이다.

Authorization Mechanisms은 크게 4가지가 있는데, 하나씩 알아보자.

- Node Authorizer: named/pods system node내에서 발생하는 요청들은 Node Authrrizer에 의해 처리된다.

권한들은 kubelet에 의해 요구되기 때문에, cluster 내에서 일어난다.

external access to API

유저마다 권한이 다른데, 이걸 하나씩 직접 policy 파일에 등록/수정해야한다.

사람이 많아질수록 관리가 어려워지는데, 이를 위해 RBAC가 나왔다.

RBAC(Role Base Access Control):

유저마다 각각 policy를 만들지 않고, Developer, Security와 같은 Role을 만들어서 유저들을 해당 role에 associate한다.

이렇게 하면, role에서 수정된 내용들이 각 user에도 모두 적용되어 관리가 쉬워진다.

opensource를 쓰고 싶다면, open Policy Agent를 쓰면 된다.

open policy agent는 3rd party tool로 admission control & authorization을 도와준다.

남은 메커니즘으로 2가지가 더 있는데, AlwaysAllow와 Always Deny로 조건없이 항상 허용/거절하는 것이다.

그럼 이런 메카니즘들을 어디에 설정할까?

kube-apiserver에 설정된다. 만약 아무 값도 설정하지 않는다면, AlwaysAllow가 default 값이 된다.

그럼, 여러 개의 모드가 작성되어 있으면?

작성된 순서에 따라 체크를 하고, 각 모드에서 관련된 것이 없다면 다음 모드로 체크한다.

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

이전 강의들에서 계속 kubeapi server와 통신했다.

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

# curl http://localhost:6443/apis -k | grep "name" // 지원되는 all resource grp

그런데, 실제로 api version을 아래와 같이 정확하게 입력하지 않고, 위와 같이 -k로 입력하면 forbidden이 발생한다.

그런데 실제로 어떻게 api verison값들을 저렇게 다 써줄 수 있을까? (복잡한데 말이다.)

그래서 kubectl Proxy를 사용한다.

먼저 kubectl proxy에 접속한 후, curl 명령어를 통해 Kube ApiServer에 접근하면 된다.

단, 여기서 말하는 kubectl Proxy는 != kube Proxy다.

Kube Proxy는 pod/service간 connectivity를 위한 인스턴스 였다면,

kubectl proxy는 kube apiserver에 접근하기 위해 kubectl utility로부터 생성된 HTTP proxy 서비스다.

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

K8s에서 client는 인증서를 사용하기 위해 curl 명령어를 이용하여 쿼리를 한다.

그런데, 명령어가 너무 길어지다보면 실수를 할 수도 있고 매일 이렇게 다 쳐주는 건 귀찮은 일이다.

그래서 kubeConfig File 개념이 나온다.

여기에 작성을 해 두고, 조회나 curl시 kubeConfig 를 이용하여 인증서를 조회할 수 있다.

그리고 kubeConfig 포맷은 크게 3가지 섹션으로 나뉘는데, 아래에서 알아보자.

크게 Clusters, Contexts, Users로 나뉜다.

Cluster는 말 그대로 시료 환경에 대한 것이고, clients 들은 k8s 환경에 접속하는 user들인데

각각 권한이 다르다.

Context는 어떤 Users가 어떤 Clusters에 접근하는지를 묶어주는 부분이다.

실제 KubeConfig file은 $HOME/.kube/config 디렉토리에 있으며,

clusters, contexts, users 섹션으로 나뉜다.

contexts의 cluster에 clusters name을 입력해주고, contexts의 user 부분에 users의 name을 입력해준다.

kubeConfig 파일은 위와 같이 조회할 수 있으며, current-context 수정은 오른쪽과 같이 가능하다.

# kubectl config view

# kubectl config use-context [변경할 내용]

그럼 다른 내용들을 수정/삭제하고 싶다면?

#kubectl config -h 를 통해 알아보면 된다.

Cluster내엔 다양한 namespace도 있을 텐데, kubeconfig에도 해당 namespace를 명시해줄 수 있다.

그리고 certificate-authority도 crt파일의 전체 path를 입력해줘야 하지만, 아예 

'certificate-authority-data'를 여기 파일에 직접 입력하는 방법도 있다. (물론 base64로)

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

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 강의