[대세는 쿠버네티스] 섹션 6. [중급편] 기본 오브젝트
<대세는 쿠버네티스> 의 섹션 6 내용을 요약 정리한 내용입니다.
대세는 쿠버네티스 [초급~중급] - 인프런 | 강의
쿠버네티스는 앞으로 어플리케이션 배포/운영에 주류가 될 기술 입니다. 이 강좌를 통해 여러분도 대세에 쉽게 편승할 수 있게 됩니다., - 강의 소개 | 인프런...
www.inflearn.com
이번 섹션에서는 앞선 기초편에서 다뤘던 기본 오브젝트에 대해 더 상세히 알아보는 섹션이였습니다. 이번에 진행되는 주제는 다음과 같습니다.
1. Service - Headless, Endpoint, Externalname
2. Volume - Dynamic Provising, StorageClass, Status, ReclaimPolicy
3. Accessing API
4. Authentication - X509 Cert, kubectl, ServiceAccount
5. Authorization - RBAC, Role, RoleBinding
1. Service - Headless, Endpoint, Externalname
기초편에서는 ClusterIP, NodePort,Load Balancer 에 대해서 알아봤었습니다. 또한 이러한 점은 모두 사용자 관점에서 궁극적으로 서비스에 연결이 되어있는 파드에 접근을 하기 위한 방법들이었습니다.
이번에는 여기서 파드의 입장에서 원하는 서비스나 파드에 직접 연결하는 방법과 외부 서비스에 안정적으로 연결하는 방법에 대해 알아보겠습니다.
1.1 Headless
모두 일단 디폴트라는 네임스페이스에 파드 2개와 서비스가 연결된 경우 입니다.
먼저 위의 경우는 ClusterIP 로 만든 서비스입니다. 파드와 서비스 모두 이름도 줬고 아이피도 동적으로 만들어졌습니다.
그리고 쿠버네티스 DNS가 있는데, 이 DNS의 이름은 Cluster.local 입니다. 이 DNS는 파드건 서비스건 생성을 하면 도메인 이름과 아이피가 저장이 된다는 특징이 있습니다.
서비스의 경우, 서비스의 이름, 네임스페이스, SVC, DNS 이름의 순서로 구성되며
파드의 경우, 아이피, 네임스페이스, 파드, DNS 이름의 순서로 구성되어 있다는 점을 알 수 있습니다.
이런 것을 FQDN 이라고 말합니다. 이를 통해 사용을 할 때, 서비스의 경우에는 앞자리만 짧게 써도 사용할 수 있지만, 파드의 경우, 전체를 입력해야 사용이 가능한 불편함과 아이피가 있기 때문에 사용하기가 더욱 힘들다는 단점이 있습니다.
위의 파드의 경우 에서의 단점을 해결하는 방법이 Headless 서비스 입니다. 만드는 방법은 서비스에서 ClusterIP 속성에 None이라고 넣어줘야하며, 파드에서는 hostname이라는 속성에 도메인 이름을 넣어야 되고 subdomain에 해당 서비스의 이름을 넣어주면 됩니다.
이렇게 만들고 나서 DNS를 확인하게 되면 ClusterIP로 만들었을때랑 동일하지만 서비스의 아이피가 없기 때문에 연결되어있는 파드의 아이피를 준다는 특징과 파드의 호스트네임, 네임스페이스, SVC, DNS 이름의 순서대로 구성되어 있다는 것을 알 수 있습니다.
이를 통해 파드의 IP를 직접적으로 알 필요 없이 간단하게 다른 파드에 연결할 수 있습니다.
1.2 Endpoint
기초편에서 서비스와 파드를 연결할 때, 라벨을 통해서 연결을 했었습니다. 하지만 이는 사용자 측면에서 이 둘을 연결하기 위한 도구일뿐 쿠버네티스의 경우에는 실질적으로는 Endpoint 라는 것을 만들어줘서, 실제 연결고리를 관리합니다.
Endpoint를 만드는 방법은 서비스의 이름과 동일한 이름으로 Endpoint의 이름을 설정하고 Endpoint 안에는 파드의 아이피 주소과 포트 등 접속정보를 넣어주면 됩니다.
그렇기에 이러한 규칙만 알면 라벨과 셀렉터 없이 직접 연결을 할 수 있습니다. 이렇게 서비스의 연결 대상을 사용자가 직접 지정을 해주기에 내부 포트 뿐만이 아니라 외부 아이피 주소로도 연결이 가능하다는 장점이 있습니다. 하지만 아이피는 항상 변경 가능성이 있다는 단점이 존재합니다.
1.3 Externalname
Endpoint의 단점을 해결할 수 있는 것이 ExternalName 입니다.
서비스에 ExternalName이라는 속성을 달아서 도메인의 이름을 넣어서 사용합니다. 이렇게 되면 DNS cache가 외부와 내부 DNS를 찾아서 아이피를 알아냅니다. 그렇기에 파드는 서비스에 연결되어 있다면 직접적인 아이피가 아닌 도메인을 통해서 연결이 가능합니다. 또한 해당 도메인 주소 변경을 통해 연결을 변경하면 되기에 파드를 수정하여 재배포를 할 필요가 없어집니다.
2. Volume - Dynamic Provising, StorageClass, Status, ReclaimPolicy
기초편에서는 emptyDir, hostPath, PVC / PV 에 대해서 알아봤었습니다. 이번에는 Dynamic Provising, StorageClass, Status, ReclaimPolicy 에 대해서 알아보겠습니다. 전체적인 개요는 위의 사진과 같습니다.
2.1 Dynamic Provising & StorageClass
Dynamic Provising을 사용하기 위해서는 사전 작업 이후 이를 지원해주는 Storage Solution 을 선택해서 설치를 해야 합니다. 이를 설치를 하게 되면 서비스, 파드 등 여러 오브젝트들이 생성이 됩니다. 이 중 가장 중요한 것은 StorageClass 라는 오브젝트 입니다. 이를 통해서 PV를 자동적으로 만들 수 있습니다.
초급편에서는 PV와 PVC를 만들고 해당 StorageClassName에 위와 같이 " " 을 넣으면 적절한 PV에 연결이 되었었습니다.
이번의 경우에는 PVC에 StorageClass의 이름을 넣게되면 자동으로 StorageOS Volume을 가진 PV가 생성됩니다. 또한 StorageClass 는 추가로 만들 수도 있고 default 설정도 가능한데 default 설정을 해주게 되면 PVC에 StorageClassName을 생략 했을 때, default StorageClass가 설정이 되서 PV가 만들어지게 됩니다.
2.2 Status & ReclaimPolicy
2.2.1 Status
PV 의 상태를 나타냅니다.
- Available : 최초 PV 가 만들어 졌을때의 상태로 PVC와 연결이 되지 않은 상태입니다.
- Bound : PVC와 연결이 된 상태로 파드가 PVC를 사용해서 구동이 될 경우 Volume 이 생성됩니다. 또한 파드가 삭제가 되더라도 PVC 와 PV에는 아무런 문제가 없기 때문에 Bound 상태로 유지됩니다.
- Released : PVC와 연결이 끊어진 상태입니다.
- Failed : 실제 데이터간의 연결에 문제가 끊어진 상태입니다.
2.2.2 ReclaimPolicy
PVC가 삭제 된 상황에 대한 경우의 정책입니다.
- Retain : 별도로 설정을 하지 않았을 경우의 기본 정책입니다. 실제 Volume의 데이터는 유지되지만, PV를 다른 PVC에 연결을 할 수는 없습니다. 그렇기에 수동으로 PV를 삭제를 해줘야합니다.
- Delete : PVC를 지우면 PV도 같이 지워집니다. 해당 정책을 StorageClass를 사용해서 자동으로 PV를 만들었을 때의 기본 정책입니다. 볼륨의 종류에 따라 실제 데이터가 삭제되기도 그렇지 않기도 합니다.
- Recycle : PV의 상태가 Available이 되면서 다시 연결할수 있는 상태입니다. 하지만 현재 이 정책은 점차 사용하지 않고 있는 정책이며, 실제 데이터가 삭제 되면서 PV를 재사용 할 수 있게 됩니다.
3. Accessing API
쿠버네티스의 API로 접근을 하는 방법에 대한 개요입니다.
3.1 user account
먼저 마스터 노드에 쿠버네티스 API 서버가 있는데 이 API 서버를 통해서만 쿠버네티스 자원을 만들거나 조회가 가능합니다. 따라 쿠버네티스를 설치할 때, kubectl를 설치해서 CLI로 자원을 조회할 수 있는 것도 모두 해당 API 서버를 통해서 가져오는 것입니다.
내부에서는 이렇게 접근이 가능하지만 외부에서 이 API 서버로 접근을 할려면 인증서를 가지고 있는 사람만 https로 보안접근이 가능합니다. 혹은 내부 관리자가 kubectl의 명령어로 proxy를 열어줘야지 인증서 없이 http로 API 서버에 접근이 가능합니다.
또한 이 kubectl은 마스터 노드 내부뿐만이 아니라 외부 PC에서도 설치를 해서 쓸 수 있는데 config 기능을 활용하면 K8s Cluster가 여러대 있더라도 명령어를 통해 접근 가능한 클러스터에 연결이 가능하며 이때 get 명령어를 통해 파드 정보들 역시 가져올 수 있습니다.
이렇게 유저들의 입장에서 API에 접근을 하는 방법을 user account라고 부릅니다.
3.2 service account
유저들의 입장이 아닌 파드의 입장에서 API에 접근하는 방법을 service account라고 부릅니다.
3.3 Authentication
User account, Service account 모두 API의 접근을 할 때, 보안을 위해 이를 확인하는 과정이 필요합니다. 이렇게 접근을 관리하는 것을 Authentication 이라고 합니다.
3.4 Authorization
접근을 한 다음 필요한 자원에 다시 접근을 할 수 있는 권한 여부에 관한 내용이 Authoriation 입니다.
3.5 Admission Control
PV를 만들때 관리자가 용량을 1기가 이상으로 만들지 못하게 설정을 했으면 파드를 만들라는 API 요청이 들어왔을 때 이를 확인하는 과정이 필요할 것입니다. 이러한 과정에 관한 것이 AdimissionControl 입니다.
4. Authentication - X509 Cert, kubectl, ServiceAccount
API 서버로 접근하는 세가지 방법입니다.
4.1 X509 Cert
다음과 같이 클러스터에 6443 포트로 API 서버가 열려있습니다. 여기로 HTTP 접근을 하기 위해선 쿠버네티스 설치시에 kubeconfig라고 해서 해당 cluster에 접근을 할 수 있는 파일이 존재합니다. 해당 파일에 다음과 같이 인증서 내용이 존재합니다. 위와 같은 인증서가 존재 해야지만 접근이 가능합니다.
CA 인증서를 만들기 위해서는 CA key를 통해 CA csr을 만들어서 만들 수 있습니다.
Client 인증서를 만들기 위해선 CA key와 CA 인증서 Client key를통해 만든 Client csr을 통해 만들 수 있습니다.
proxy를 열어서 외부에서 http를 통해서 접근이 가능한 이유는 쿠버네티스를 설치할 때 kubectl도 설치를 하고 설정 내용 중에 kubeconfig 파일을 복사했기 때문에 kubectl이 인증서를 갖고 있어서 API 인증이 되기 때문에 접근이 가능합니다.
4.2 kubectl
kubectl의 내부에 있는 kubeconfig 파일에는 clusters와 users, contexts가 존재합니다.
Clusters를 통해서 클러스터를 등록할 수 있고 내용으로는 이름과 연결 정보, CA 인증서가 존재합니다.
Users를 통해서 사용자를 등록할 수 있고 내용으로는 이름과 해당 유저에 대한 개인키와 인증서가 존재합니다.
Contexts를 통해서 clusers와 users를 연결할 수 있고 내용으로는 이름과 연결할 클러스터, 유저 이름이 존재합니다.
kubectl config user-context "contexts 이름"
또한 kubeconfig 내에 이러한 파일을 여러개 등록하여 위와 같은 명령어로 사용할 contexts를 지정할 수 있습니다.
4.3 ServiceAccount
쿠버네티스 클러스터와 API 서버가 있고 네임스페이스를 만들게 되면 기본적으로 default라는 이름의 ServiceAccount가 자동으로 만들어집니다. 또한 여기에 Secret이 하나 달려있는데 내용으로는 CA crt 정보와 토큰값이 들어있습니다.
이때 파드를 만들면 해당 ServiceAccount가 연결이 되고 파드는 이 토큰값을 통해서 API 서버에 연결을 할 수 있습니다.또한 토큰값만 알면 사용자 역시 해당 하는 값을 가지고 API 서버에 접근할 수가 있게 됩니다.
5. Authorization - RBAC, Role, RoleBinding
쿠버네티스가 자원에 대한 권한을 지원하는 방법에 관한 내용입니다.
쿠버네티스에는 클러스터 단위로 관리되는 자원과 네임스페이스 단위로 관리되는 자원으로 나눌수 있습니다.
또한 네임스페이스를 만들면 자동적으로 ServiceAccount 가 만들어지기도 하고 추가적으로 더 만들수도 있는데, ServiceAccount 에 Role과 RoleBinding 을 어떻게 설정을 하냐에 따라 해당 ServiceAccount 는 네임스페이스 내의 있는 자원에만 접근을 할수도 있고 아니면 클러스터에 있는 자원에도 접근을 할 수가 있게 됩니다.
Role은 여러개를 만들 수가 있고 각 Role에는 여러가지 케이스로 만들 수도 있습니다. 이때 함께 나오는 것이 RoleBinding 입니다. 이는 Role과 SA를 연결해 주는 역할을 합니다. RoleBinding 은 여러개의 ServiceAccount 를 지정할 수 있으니 Role은 하나만 지정이 가능하다는 특징이 있습니다.
이렇게 연결된 Role 에따라 ServiceAccount 은 API 서버의 접근하여 해당 역할의 권한을 얻게 됩니다.
ClusterRole과 ClusterRoleBinding 역시 위의 Role과 RoleBinding과 역할은 동일하나 클러스터 단위로 관리되는 오브젝트들을 지정한다는 점이 차이점입니다.
이때 RoleBinding을 통해 ClusterRole에도 연결이 가능한데 이러한 경우는 모든 네임스페이스 마다 똑같은 Role을 부여하고 관리해야 하는 상황에서 한번에 관리를 가능하게 해주는 장점이 있습니다.