[Kubernetes Best Practice] 2. 개발자 워크플로

이 글은 Kubernetes Best Practice를 읽고 개인적으로 중요하다고 생각하는 부분과 잘 모르는 부분에 대해 공부한 내용을 작성한 글입니다. 모든 내용은 책에 포함되어 있는 내용을 기반으로 작성하였으며 자세한 내용이 궁금하신 분들은 책을 구매해서 읽는 것을 권장드립니다. 

최근 서비스 메시에 대해 알아보거나 쿠버네티스를 사용하고 공부하면서 가장 많이 들었던 생각은 이 방법이 최선인가? 라는 생각이었습니다. 이에 대한 궁금증을 해결하는데 도움이 될만한 책을 발견해서 읽어보고자 합니다.

---

개발단계에서 쿠버네티스 활용

Kubernetes를 통해 애플리케이션의 배포 및 관리 측면에서 많은 이점을 얻을 수 있습니다. Controller를 통한 Reconcile 로직 수행, Deployment를 통한 Rollout과 같은 기능이 이에 해당합니다. 하지만 어플리케이션을 개발하는 입장에서도 쿠버네티스를 도입함으로써 이점을 얻으려면 쿠버네티스 클러스터를 운영 단계에서만 사용하는 것이 아닌 개발 단계에서의 편의성을 위해서도 활용해야 합니다.

개발 과정에서 쿠버네티스를 사용하며 고려할 부분에 대해서는 다음과 같은 부분들을 언급하고 있습니다.

• 클러스터에 작성한 코드를 빠르게 테스트할 수 있어야 합니다.
• merge 전 모든 테스트가 자동으로 수행되어야 합니다.
• 클러스터 환경 문제로 인해 테스트가 실패하지 않아야 합니다.

---

개발용 클러스터 구축

개발용 클러스터를 사용하는 방법은 팀별(혹인 개인별)로 클러스터를 할당하는 방법과 단일 클러스터 내부에서 네임스페이스를 통해 구축하는 방법이 존재합니다. 인턴을 진행했던 곳에서는 후자의 방법을 제공했었고 당시 이유에 대해 궁금했었는데... 각 방법의 장단점을 파악해보겠습니다. 

먼저 개별적인 클러스터를 제공하는 방법의 가장 큰 단점은 비용과 관리해야할 대상이 많아진다는 점입니다. 또한 클러스터의 사용률이 비효율적일 가능성이 높아질 수 있습니다. (기본으로 할당된 클러스터의 스펙이 오버스펙이 될 수도..) 하지만, 클러스터가 분리되어 있기 때문에 사용자간의 간섭이 없다는 장점이 존재합니다.

다음으로 단일 클러스터 내부에서 네임스페이스를 통해 구축하는 방법에 대해서 생각해보겠습니다. 가장 큰 장점은 역시 비용입니다. 같은 인원이라고 할 경우에 더 작은 클러스터가 필요하기 떄문에 클러스터 운영 비용이 감소하게 됩니댜(또한 책에서는 모니터링과 같은 개발자에게 필요한 시스템을 설치하기가 용이하다고 하는데 이유가 이해되지 않아서 일단 보류).  하지만, 사용자 간 간섭이 발생할 가능성이 증가하기 떄문에 리소스 관리 및 RBAC를 통한 권한 제어가 필요합니다. 

추천하는 방법은 후자로 이를 도입함에 있어 새로운 사용자를 추가하는 온보딩 과정과 사용자 권한 및 리소스 관리, 그리고 낭비되고 있는 리소스가 없는지 관리하는 작업에 시간을 투자해야 합니다.

---

다음으로는 공용 클러스터를 구축하여 사용자에게 네임스페이스를 할당하는 과정에 대해 간략하게 요약한 내용입니다.

온보딩 프로세스

사용자가 네임스페이스를 할당 받기 위해서는 먼저 클러스터에 접근할 수 있는 권한이 있어야 합니다. 권한을 부여하기 위한 방법으로는 새롭게 생성한 kubeconfig 파일을 전달하는 방법이나 AWS IAM과 같은 외부 신원 시스템을 통해 접근 권한을 설정하는 방법이 존재합니다. 일반적으로는 신원 데이터 관리 측면에서 외부 신원 시스템을 사용하는 것이 모범 사례이지만, 제한되는 경우 전자의 방법을 사용할 수도 있습니다.

책에서는 새로운 사용자를 위한 pem파일과 csr 파일을 생성하고 이를 통해 새로운 증명을 생성, 다운로드하는 방법에 대해서 소개합니다. 새로운 사용자는 Kubernetes에서 발급한 인증서를 가지고 있어야하고, 이 인증서를 API 호출의 Certificate Header로 제공하거나 kubectl을 통해 제공해야 합니다.

사용자 증명 생성

가장 먼저 해야하는 작업은 private key와 CSR을 발급받는 작업입니다. 다양한 방법이 존재하기 때문에 이 부분은 따로 다루진 않지만 다음 작업을 수행하기 위해서는 key.pem 파일과 csr 파일이 존재해야 합니다.

다음으로 유저를 추가하기 위해서는 Kubernetes에 인증서 발급을 요청하는 CertificateSigningRequest 리소스를 생성해야 합니다(책에서 사용한 api 버전은 v1beta1이지만 문서를 보면 v1을 사용하고 있고, v1 버전에서는 signerName 필드가 필수로 변경되었습니다).

cat <<EOF | kubectl create -f -
apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
    name: ${csr_name}
spec:
    groups:
    - system:authenticated
    request: $(cat ${csr} | base64 | tr -d '\n')
    signerName: kubernetes.io/kube-apiserver-client
    usages:
    - digital signature
    - key encipherment
    - client auth
EOF

 

다음으로 kubectl을 통해 CSR을 생성하고 이를 승인해야합니다. 승인 작업이 완료되었으면 csr을 통해 crt 파일을 생성합니다.

> kubectl certificate approve <csr_name>
> kubectl get csr/<csr_name> -o jsonpath='{.status.certificate}' \
	| base 64 --decode > <csr_name>.crt

 

마지막으로 crt파일과 pem 파일을 kubeconfig에 추가함으로써 새로운 유저를 사용할 수 있습니다.

kubectl config set-credentials <user_name> \
--client-key=<key-file> \
--client-certificate=<crt=file> \
--embed-certs=true

참고 글 : kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/

---

Namespace 접근 권한 부여

위의 과정을 통해서 새로운 사용자를 활성화 할 수 있지만 네임스페이스에 대한 권한을 부여해야 합니다. 특정 사용자에게만 네임스페이스 접근 권한을 부여하기 위해 RoleBinding을 사용합니다.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
    name: user-role-binding
    namespace: my-namespace
roleRef:
  apiGroup: rbac.authorization.k8s.io/v1
  kind: ClusterRole
  name: edit
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: myuser

여기서 왜 ClusterRole과 바인딩하는지 개인적으로 궁금해서 생각해봤는데 저자는 Role을 따로 만들지 않고 기존에 존재하는 clusterRole을 사용하기 위해서 이렇게 작성한 것으로 예상됩니다. 문서에 따르면 ClusterRole을 RoleBinding을 통해 바인딩 하는 경우 지정한 네임스페이스 안에서 ClusterRole의 권한을 가지게 됩니다. 

권한을 부여할 때 다른 네임스페이스의 작업을 보기 위해 전체 클러스터에 읽기 권한을 부여하는 것이 실용적이라고 합니다. 여기서 시크릿 리소스에 대해서는 읽기 권한을 제외시켜 해야한다는 점을 주의해야 합니다.

---

리소스 사용량 제한

특정 네임스페이스가 클러스터 전체의 리소스에 영향을 주지 않게 하기 위해서 네임스페이스 별로 리소스 사용량을 제한해야 합니다. Kubernetes에서는 ResourceQuota를 통해 이러한 기능을 제공합니다. 

---

네임스페이스 관리

특정 사용자에게 네임스페이스를 할당할 때 생성 과정에서 바로 할당해주는 방법은 네임스페이스가 영구적으로 사용되기 때문에 개별 리소스를 파악하고 필요없는 리소스를 삭제하기 어려울 수 있습니다. 이에 대한 대안으로는 TTL을 지닌 네임스페이스를 생성, 할당하는 방법으로 클러스터의 자원을 효율적으로 사용할 수 있습니다. TTL을 사용하는 방법으로 네임스페이스를 생성 및 할당할 때 네임스페이스에 TTL을 비롯한 개발자, 리소스 정보와 같은 메타 데이터를 포함시켜 이후 리소스 사용량에 대한 추적을 보다 용이하게 만들 수 있습니다.

책에서는 동적으로 새로운 네임스페이스를 생성할 수 있는 CRD를 구현해보는 방법에 대해 언급하고 있다. 다음 글에서는 이 부분에 대해 다뤄보는 걸로 해야겠다.

---

클러스터 수준의 서비스 제공

클러스터를 사용하는 개발자의 편의성과 생산성을 향상시키기 위해서는 로깅, 모니터링과 같은 인프라 서비스를 제공하는 것도 고민할 필요가 있습니다. 개인적으로 인턴을 진행했던 곳에서는 prometheus 및 grafana를 통한 기본적인 모니터링 대시보드가 제공되었는데 덕분에 장애 발생 시 원인을 파악하기 수월했던 경험이 있습니다.

---

지금까지 단순히 클라우드 플랫폼에서 제공해주는 구축된 쿠버네티스 클러스터만 사용했었는데, 실제 개발자에게 제공하기 위해 어떤 과정이 필요하고 어떤 것들을 고려해야 하는지 조금은 알 수 있게 되었던 파트였다고 생각합니다.