kubeConfig
kubeconfig는 kubectl cli를 설정하는 configuration 파일으로, 어떤 kube-apiserver에 어떤 ca, cert 파일을 토대로 상호작용할 것인지를 설정할 수 있다.
가령, my-kube-playground:6443에 요청을 보낸다고 할 때, 다음과 같이 설정할 수 있다.
- config
--server my-kube-playground:6443
--client-key admin.key
--certificate-authority ca.crt다음의 설정 파일을 kubectl에서 --kubeconfig 명령어로 가져올 수 있다.
kubectl get pods --kubeconfig config위와 같이 --kubeconfig 옵션을 통해서 configuration 파일을 지정할 수 있지만, default 위치에 config파일을 지정해두면 옵션을 지정하지 않아도 해당 config파일을 읽을 수 있게 된다.
즉, 위의 config파일 내용을 $HOME/.kube/config로 파일을 위치시키면 kubectl get pods로 호출이 가능한 것이다.
kubeconfig file은 크게 3개의 구조를 갖는다.
- clusters: cluster의 다양한 버전을 나눈다. 가령 development, production 등의 다양한 kubernetes cluster를 둘 수 있다.
- users: user account로 admin, dev user, production user등을 지정할 수 있다. 각 유저는 다른 권한을 갖을 수 있게 한다.
- contexts: user와 cluster를 조합하여, 어떤 유저가 어떤 cluster에 접근할 것인지 정의한다. 가령 admin유저가 production cluster에 접근하는 context를 만든다면
admin@production처럼된다. 이렇게 설정해두면, 각 유저가 어떤 cluster에 접근하고 어떤 보안 설정을 해야하는 지 매번 써야할 필요가 없다.
즉, context는 어떤 user가 어떤 cluster에서 에서 어떤 보안 정보와 권한을 가지고 접근할 것인지를 결합해놓은 것이다.
이 3개의 section이 다음과 같이 정의가능하다.
apiVersion: v1
kind: Config
current-context: my-kube-admin@my-kube-playground
clusters:
- name: my-kube-playground
cluster:
certificate-authority: ca.crt
server: https://my-kube-playground:6443
users:
- name: my-kube-admin
user:
client-certificate: admin.crt
client-key: admin.key
contexts:
- name: my-kube-admin@my-kube-playground
context:
cluster: my-kube-playground
user: my-kube-adminkubeconfig 파일을 잘보면 각 section들이 배열을 넣는 것을 알 수 있다. 따라서 여러개의 cluster, user들이라해서 하나의 config파일로 여러 context를 모두 처리할 수 있는 것이다.
다음의 config파일은 kubernetes api server를 통해서 굳이 object로 만들 필요없이 $HOME/.kube/config에 넣어주기만 하면 된다.
kubectl은 current-context를 보고서는 어떤 context를 사용할 지 결정하는 것이다.
다음의 명령어를 통해 현재 적용중인 config파일의 정보를 확인할 수 있다.
kubectl config view
apiVersion: v1
kind: Config
current-context: kubernetes-admin@kubernetes
...
contexts:
- context:
name: kubernetes-admin@kubernetes
cluster: kubernetes
user: kubernetes-admin
...만약 custom하게 만든 configuration파일로 바꾸고 싶다면 다음과 같이 사용하면 된다.
kubectl config view --kubeconfig=my-custom-config만약 context를 바꾸고 싶다면 use-context명령어를 사용하면 된다. 가령 prod-user@production으로 바꾸고 싶다면 다음의 명령어를 사용하면 된다.
kubectl config use-context prod-user@production
apiVersion: v1
kind: Config
current-context: prod-user@production
...
contexts:
- name: my-kube-admin@my-kube-palyground
- name: prod-user@production
...위와 같이 kubeconfig를 통해 어떤 user가 어떤 cluster에 접근할 것인지에 대한 정보를 제공할 수 있는데, 이는 namespace역시도 마찬가지이다. 즉, 기본 namespace가 default가 아니라 다른 값으로 지정하여 매번 호출 때마다 namespace를 명시하지 않아도되는 경우들이 있다.
apiVersion: v1
kind: Config
current-context: my-kube-admin@my-kube-playground
clusters:
- name: my-kube-playground
cluster:
certificate-authority: ca.crt
server: https://my-kube-playground:6443
users:
- name: my-kube-admin
user:
client-certificate: admin.crt
client-key: admin.key
namespace: finance
contexts:
- name: my-kube-admin@my-kube-playground
context:
cluster: my-kube-playground
user: my-kube-admin위의 경우 my-kube-admin context로 전환되면 kubectl 명령어의 namespace가 finance로 된다. 따라서 default namespace에 접근하려면 kubectl get pods -n default로 써야하고 finance namespace에 접근하려면 kubectl get pods로 쓰면 된다.
cluster certificate data 설정
kubeconfig파일에 CA정보를 넣을 때, 위에서는 path정보를 제공하여 file을 넣어주었다.
apiVersion: v1
kind: Config
current-context: my-kube-admin@my-kube-playground
clusters:
- name: my-kube-playground
cluster:
certificate-authority: /etc/kubernetes/pki/ca.crt
server: https://my-kube-playground:6443그러나 certificate-authority 대신에 certificate-authority-data라는 field를 쓸 수 있는데, 이는 ca.crt에 있는 data를 base64로 인코딩하여 제공하면 된다.
즉, /etc/kubernetes/pki/ca.crt data를 base64인코딩 한 뒤에 나온 결과를 certificate-authority-data에 넣어주면 되는 것이다.
/etc/kubernetes/pki/ca.crt | base64
LSQtLsS1CRUdJTiBDRVJU...PbnJ해당 결과를 certificate-authority-data에 넣어주면 다음과 같다.
apiVersion: v1
kind: Config
current-context: my-kube-admin@my-kube-playground
clusters:
- name: my-kube-playground
cluster:
certificate-authority-data: LSQtLsS1CRUdJTiBDRVJU...PbnJ
server: https://my-kube-playground:6443이렇게해도 성공한다.
