1. Volumn
이전에 PV, PVC를 배웠는데 다시 기억해보자.
- PV: persistent volumn으로 볼륨의 크기, 접근 권한을 설정하여 Cloud Admin이 미리 구성한다.
- PVC: persistent volumn claim으로 기본적인 스펙 및 권한을 설정하고 개발자고 필요한 경우 생성하여 사용한다.
=> 즉 PV를 우선적으로 생성해놓고 개발자가 필요시 PVC를 생성하면 조건에 맞는 PV와 연결하여 우리는 사용한다는 것의 이전 강의 였다.
하지만 위 방식은 문제가 있다. 필요시 마다 PV를 만들어야 되고 해당 PVC와 PV를 연결해야 한다는 단점이 존재하는데 이를 해결하는 방식이 Dynamic Provisioning이다.
이 방식을 통해 사용자가 PVC를 만들기만하면 동적으로 PV를 만들고 이를 연결해준다.
또 볼륨 구성을 구성하는 방법에는 여러가지가 있다.
- 쿠버네티스 노드 자체를 이용하는 것
- 온 프레미스 솔루션을 붙이는 법
- NFS를 이용해서 서버하나를 붙이는 법
- 외부 스토리지 Saas 연동
해당 Dynamic Provisioning을 설정하기 위해서는 StorageClass를 구성해야 한다. 해당 클래스를 설정해놓으면 해당 설정이 있는 PVC와 자동적으로 연결이 된다.
PV의 상태에는 총 4가지가 있는데
- Available: 최소 PV가 생성됬을 때 상태
- Bound: PVC와 연결이 되었을 때 만일 pod가 삭제되었다 하여도 볼륨은 문제가 없기 때문에 상태가 유지된다.
- Released: PVC와 연결이 끊어진 상태
- Failed: PV의 실제 데이터 연결에 문제가 생긴 상태
또 PVC와 연결이 끊어졌을 때 PV정책 3가지가 있다.
- Retain: PVC가 연결이 끊어지면 데이터를 보존하고 재사용은 불가한다
- Delete: Volumn에 따라 데이터 삭제 및 재사용 불가
- Recycle: “ rm -rf /thevolume/* ” 으로 데이터를 전부 삭제 후 재 사용할 수 있게 설정
엔지니어링 관점에서 forced rm, scrub은 볼륨의 메타 데이터도 전부 삭제하기 때문에 위험
2. Accessing API
쿠버네티스 마스터 노드의 구성은 위와 같다. User의 접근을 위한 User Account가 존재하고 이 User Account를 통해 우리는 마스터 노드의 객체에 접근이 가능하다. 또 각 네임스페이스의 객체에서 마스터 노드의 접근을 하기 위해 Service Account가 존재한다.
1) Authentication
외부에서 k8s apiserver를 접근하기 위한 인증 방법을 정리
X509 Client Certs
마스터 노드에 존재하는 클라이언트 인증서, 키를 복사해서 k8s apiserver를 직접 http call한다.
-> 우리 회사에서는 Azure를 사용하는데 Azure 환경에서는 마스터 노드로 접근이 불가한다고 한다. ㅠ ㅠ
-> kubeadm은 mac or window 서버에서 지원
kubectl
kubectl을 사용해서 많은 클러스터를 등록해두고 Context를 변경하며 사용하는 방식
해당 방식을 아마 가장 많이 사용하지 않을까 싶다.
# local docker cluster로 변경
~ main* ❯ k config use-context docker-desktop
Switched to context "docker-desktop".
~ main* ❯ k get nodes
NAME STATUS ROLES AGE VERSION
docker-desktop Ready control-plane 86d v1.27.2
#Azure cluster로 변경
~ main* ❯ k config use-context backend-sandbox
Switched to context "backend-sandbox".
~ main* ❯ k get nodes
NAME STATUS ROLES AGE VERSION
aks-agentpool-14929390-vmss000000 Ready agent 13d v1.26.10
aks-userpool-14929390-vmss000001 Ready agent 13d v1.26.10
# kubectx를 이용해서 변경하는 것과 동일
~ main* ❯ x docker-desktop
Switched to context "docker-desktop".
~ main* ❯ x backend-sandbox
Switched to context "backend-sandbox".kubectl config get-contexts위의 코드들은 kubectl에서 주로 사용하는 명령어들의 예시이다.
ServiceAccounts - Secret
마스터 노드에 external ip가 존재하는 경우 확인이 가능한 방법이다. 해당 서비스의 토큰 값을 이용해 접근이 가능하다록 한다.
k8s 1.24 버전부터는 Service Account를 생성해도 자동으로 secret token이 생성되지 않아 아래 명령어를 통해 생성해줘야 한다.
k creat token {serviceaccount name} -n {namespace}apiVersion: v1
kind: Secret
metadata:
name: sa-token
namespace: nm-01
annotations:
kubernetes.io/service-account.name: default
type: kubernetes.io/service-account-tokenAuthorization
접근 후 클러스터 내의 자원을 제어, 접근 범위를 설정하는 과정
RBAC
우선 Role을 생성하고 해당 접근 제어 방식을 설정한다. 그 다음 RoleBinding을 설정해 각 ServiceAccount를 연결하면 ServiceAccount들은 연결되어 있는 role의 방식에 따라서 각 네임스페이스의 객체에 접근이 가능하다.
클러스터 내부의 객체에도 접근 제어가 가능한데 여기서는 ClusterRole과 ClusterBinding을 사용하고 사용방식은 기존의 Role과 같다.
그렇다면 RoleBinding과 ClusterRole 끼리는 연결이 가능할까?
정답은 가능하다 이다. 해당 방식으로 연결하면 외부 클러스터로 접근은 불가하지만 내부 네임스페이스 객체로써의 접근만 가능하다. 즉 기존의 Role을 사용하는 방식과 같다.
그렇다면 해당 방식을 사용하는 이유는 뭘까 만일 각각의 namespace에 같은 role을 지정하고 싶으면 우리는 모든 네임스페이스 내부에 role을 생성해주고 연결을 해주어야 한다. 하지만 clusterRole을 하나만 생성하주고 연결해준다면 우리는 이와 같은 번거로움을 가질필요가 없어진다.
