study/devops

쿠버네티스 (Kubernetes, k8s) 오브젝트

FYE 2023. 2. 16. 22:16

앞서 쿠버네티스의 다양한 오브젝트들에 대해서 공부했었다.

 

  • Pod - 컨테이너의 실행을 담당하는 가장 작은 배포 단위
  • Service - 여러 개의 Pod에 대한 로드 밸런싱 및 서비스 디스커버리기능을 제공
  • Deployment - ReplicaSet 오브젝트를 관리하며, 애플리케이션의 롤링 업데이트 및 롤백을 수행
  • StatefulSet - 상태가 있는 애플리케이션, 예를 들어 데이터베이스와 같은 애플리케이션을 관리

 

이외의 오브젝트들에 대해 추가로 알아보고 싶어서 게시글을 작성한다.

 

Namespace

사진출처 : https://wiki.webnori.com/display/kubernetes/Namespace

 

네임스페이스 (Namespace)는 클러스터 내에서 리소스를 구분하고 격리하는 데 사용되는 가상 클러스터이다.

각 네임스페이스는 고유한 이름으로 식별되며, 다른 네임스페이스 내의 리소스와 격리되어 있다.

즉, 같은 이름의 리소스가 다른 네임스페이스에서는 동일한 이름의 리소스와 충돌하지 않는다.

 

네임스페이스를 사용하면 동일한 클러스터 내에서 여러 팀, 프로젝트 또는 환경에 대한 리소스를 구분하고 격리할 수 있다.

예를 들어 팀A는 "prod" 네임스페이스에서 애플리케이션을 실행하고, 팀 B는 "dev" 네임스페이스에서 애플리케이션을 실행할 수 있다.

각 네임스페이스에서는 별도의 액세스 제어 규칙을 정의하고, 네트워크를 격리하여 리소스 간의 충돌을 방지할 수 있다.

 

 

  • 사용자별 네임스페이스별 접근권한을 다르게 운영
  • 네임스페이스별로 리소스 할당량 지정 ( 개발계는 CPU100, 운영계는 CPU400)
  • 네임스페이스별로 리소스 나눠서 관리가능 (Pod, Service)

 

쿠버네티스에서는 기본적으로 "default"라는 네임스페이스가 생성되고, 이외에도 사용자 정의 네임스페이스를 생성할 수 있다.

 

네임스페이스를 생성하려면 아래와 같은 명령을 사용하면 된다.

kubectl create namespace <namespace-name>

 

현재 클러스터에 있는 모든 네임페이스를 확인하려면

kubectl get namespcaes

명령을 통해 네임페이스를 확인할 수 있다.

 

 

 

 

이미지를 재사용하면 애플리케이션 배포를 훨씬 빠르고 쉽게 할 수 있으며 배포되는 애플리케이션의 일관성을 유지할 수 있다.

또한 보안을 강화할 수 있기때문에 가급적 컨테이너 이미지는 재사용 가능하게 만드는 것이 좋다.

 

동일한 이미지는 개발/스테이징/운영 환경에 사용될 수 있어야 하며 이미지가 애플리케이션과 서비스 전반에 걸쳐 사용하기에 충분하도록 범용적이면 더 좋다.

 

새로운 환경과 개발에 따른 이미지의 재구성은 테스트와 버전관리가 복잡해지며 그만큼 위험성이 높아진다.

Configmap은 작업 부하에 대한 설정 정보를 제공하는 데 사용되며, Secret는 민감한 정보, 자격증명, 인증서, 암호등과 같은 항목으로 쓰일 수 있다.

 

 

ConfigMap

애플리케이션 구성 정보를 저장하는 데 사용된다. 구성정보는 애플리케이션에 필요한 환경 변수, 설정 파일 등을 포함할 수 있다.

이러한 구성 정보를 ConfigMap에 저장하면 애플리케이션 배포 시 구성 정보를 쉽게 관리할 수 있다.

예를 들어 애플리케이션의 구성 정보가 변경되면 ConfigMap을 업데이트하고, 이를 참조하는 모든 애플리케이션 컨테이너가 자동으로 업데이트된다.

 

Secret

애플리케이션에서 사용되는 민감한 데이터(ex : 데이터베이스 비밀번호, API 키 )를 안전하게 저장하는 데 사용된다. Secret은 ConfigMap과 유사하지만 데이터가 암호화되어 저장되며, 필요한 경우 복호화되어 애플리케이션에서 사용됩니다. 이를 통해 민감한 데이터가 노출되는 것을 방지할 수 있습니다.

 

ConfigMap과 Secret을 사용하면 애플리케이션의 구성 정보와 민감한 데이터를 쉽게 관리할 수 있으며 보안에 민감한 정보를 안전하게 보호할 수 있다. ConfigMap과 Secret을 사용하면 환경변수나 볼륨마운트를 통해 컨테이너에 쉽게 제공할 수 있기 때문에 애플리케이션을 배포하거나 업데이트하는 데 유용하다.

 

 

*볼륨마운트

컨테이너화된 애플리케이션은 일반적으로 컨테이너 이미지 안에 포함된 파일 시스템을 사용한다. 그러나 컨테이너 이미지 안에 포함된 파일만 사용하면, 파일이 수정되더라도 컨테이너 이미지 안에 포함된 파일만 사용하면, 파일이 수정되더라도 컨테이너 이미지를 다시 빌드하고 배포해야한다. 이러한 작업은 번거로울 뿐만 아니라 많은 시간이 소요될 수 있다.

볼륨 마운트는 이러한 문제를 해결하기 위해 사용된다. 볼륨 마운트를 사용하면 호스트 머신의 파일 시스템이나 네트워크 스토리지와 같은 외부 저장소를 컨테이너에서 사용할 수 있다. 이를 통해 컨테이너가 데이터를 유지하면서도 컨테이너 이미지와는 분리된 외부 저장소에서 데이터를 관리할 수 있습니다.

따라서, ConfigMap이나 Secret을 사용하여 구성 정보나 민감한 데이터를 관리할 때, 이를 볼륨으로 마운트하여 컨테이너가 테이터에 쉽게 액세스 할 수 있도록 할 수 있다.

 

 

 

 

 

 

ServiceAccount 

쿠버네티스에서는 Pod이나 컨테이너에서 API 서버에 인증하여 클러스터 상의 자원을 조작할 수 있다. 이때 사용되는 것이 ServiceAccount이다.

 

쿠버네티스 내에서 인증 정보를 저장하고, Pod이나 컨테이너에서 해당 인증 정보를 사용하여 쿠버네티스 API 서버와 통신할 수 있도록 합니다. 즉, ServiceAccount를 사용하면 Pod이나 컨테이너는 클러스터 자원에 대한 액세스 권한을 부여받을 수 있다.

 

각 Pod은 생성될 때 자체 ServiceAccount를 가진다. 기본적으로 ServiceAccount는 namespace의 이름으로 생성되며, 이는 Pod에서 사용 가능합니다. Pod이나 컨테이너에서 ServiceAccount를 사용하려면 컨테이너에서 사용할 ServiceAccount 이름을 지정해야 한다.

ServiceAccount는 클러스터 레벨에서 생성되고 관리됩니다. 따라서 다른 namespace의 ServiceAccount를 사용하거나, 새로운 ServiceAccount를 생성하려면 권한이 있는 사용자나 서비스 계정이 해당 작업을 수행해야 한다.

 

 

 

 

 

Role/ClusterRole 

쿠버네티스에서는 Role과 CluseterRole 리소스를 사용하여 사용자나 서비스 계정이 클러스터 리소스에 대한 액세스 권한을 관리한다.

 

Role : Role은 namespace 안에서 사용됩니다. 특정 namespace내에서 리소스에 대한 액세스 권한을 제어할 수 있습니다. 즉, Role을 사용하면 특정 namespace에서 권한을 관리할 수 있습니다. 예를 들어, 특정 namespace에 대해 Pod을 읽고 생성할 수 있는 권한을 부여할 수 있음

 

ClusterRole : ClusterRole은 namespace에 상관없이 클러스터 전체에서 사용된다. 즉, ClusterRole을 사용하면 클러스터 전체에서 권한을 관리할 수 있다. 예를 들어, 모든 namespace에서 configmap을 읽고 수정할 수 있는 권한을 부여할 수 있다.

 

Role과 ClusterRole은 각각의 권한 범위에 따라 다르게 사용된다. 사용자나 서비스 계정이 권한을 요청할 때, 요청한 리소스와 액세스 수준을 지정하여 Role 또는 ClusterRole을 참조하게 된다. 그리고 해당 Role 또는 ClusterRole이 권한을 부여하거나 거부한다.

 

 

 

Controller 

쿠버네티스 컨트롤러는 쿠버네티스에서 파드, 디플로이먼트, 데몬셋 등과 같은 여러 가지 리소스를 관리하는 역할을 한다. 쿠버네티스 클러스터에서는 컨트롤러를 사용하여 클러스터 상태를 지속적으로 모니터링하고, 필요한 변경 사항을 감지하고, 리소스를 적절하게 확장하거나 축소하고, 장애 상황을 대처하는 등의 작업을 수행한다.

 

쿠버네티스 컨트롤러에는 여러 종류가 있는데 가장 일반적으로 사용되는 컨트롤러는 다음과 같다.

 

ReplicaSet 컨트롤러 : 레플리카셋 컨트롤러는 파드의 복제본 수를 관리한다. 사용자가 지정한 수만큼 복제본을 생성하고, 파드의 상태를 모니터링하여 문제가 발생하면 대처한다.

 

Deployment 컨트롤러 : 디플로이먼트 컨트롤러는 레플리카셋 컨트롤러를 기반으로 하며, 애플리케이션 배포를 관리한다. 새로운 버전의 애플리케이션을 롤아웃하거나 이전 버전으로 롤백하는 등의 작업을 수행한다.

 

StatefulSet 컨트롤러 : 스테이트풀셋 컨트롤러는 고유한 식별자를 가진 파드를 관리한다. 이를 통해 애플리케이션에 필요한 고유한 네트워크 식별자와 스토리지를 지원한다.

 

DaemonSet 컨트롤러 : 데몬셋컨트롤러는 모든 노드에서 실행되는 파드를 관리한다. 예를 들어 로그수집기나 모니터링 에이전트와 같은 시스템 수준의 서비스를 실행할 때 사용된다.

 

Job 컨트롤러 : 잡 컨트롤러는 일회성 작업을 실행한다. 특정 작업을 실행하고 성공 또는 실패 여부를 확인한 후에는 파드를 삭제한다.

 

 

컨트롤러를 사용하면 많은 작업을 자동화할 수 있으며 이는 운영 비용을 줄이고 애플리케이션의 가용성을 높이는 데 도움이 된다.

 

 

 

 

참고 레퍼런스

https://wiki.webnori.com/display/kubernetes/Namespace

https://kubernetes.io/ko/docs/concepts/overview/working-with-objects/namespaces/

https://kubernetes.io/docs/concepts/configuration/configmap/

https://wiki.webnori.com/pages/viewpage.action?pageId=12583285

저작자표시 비영리 동일조건 (새창열림)