StatefulSet는 상태 저장 애플리케이션을 관리하는 데 사용되는 Kubernetes의 API 객체입니다. Kubernetes에는 Stateful 애플리케이션과 Stateless 애플리케이션이라는 두 가지 유형의 애플리케이션이 있습니다. 이러한 애플리케이션을 배포하는 방법에는 두 가지가 있습니다.
어떤 형태로든 지속적인 상태나 데이터를 유지하는 애플리케이션을 상태 저장 애플리케이션이라고 합니다. 상태 비저장 애플리케이션과 구별되는 주요 특징은 이러한 애플리케이션이 데이터를 로컬에 저장하는 데 의존하지 않고 각 요청을 독립적으로 처리하지 않는다는 것입니다. 상호 작용 간의 데이터를 관리합니다. 때로는 상태 비저장 애플리케이션이 상태 저장 애플리케이션에 연결하여 요청을 데이터베이스로 전달하는 경우도 있습니다.
어떤 형태의 지속적인 상태나 데이터도 로컬에서 유지하지 않는 애플리케이션을 무상태 애플리케이션이라고 합니다. 상태 비저장 애플리케이션에서는 각 요청이나 상호 작용이 독립적으로 처리됩니다. 이러한 애플리케이션은 상태 저장 애플리케이션과 달리 과거 상호 작용이나 요청을 추적할 필요가 없기 때문에 확장성이 뛰어나고 관리가 쉽고 내결함성을 갖도록 설계되었습니다.
상태 비저장 애플리케이션은 배포 구성 요소를 사용하여 배포됩니다. 배포는 포드를 추상화한 것이며 애플리케이션을 복제할 수 있게 해줍니다. 즉, 동일한 상태 비저장 애플리케이션의 동일한 포드를 1개, 5개, 10개 또는 n개까지 실행할 수 있습니다.
간단히 말해서 StatefulSet는 상태 저장 애플리케이션에 특별히 사용되는 Kubernetes 구성 요소입니다. 상태 저장 애플리케이션을 관리하는 데 사용되는 워크로드 API 개체입니다. 이들은 포드 세트의 배포 및 확장(더 많은 복제본 생성 또는 삭제)을 관리하며 StatefulSet는 이러한 포드의 순서와 고유성도 담당합니다. StatefulSet은 Kubernetes 1.9 릴리스에서 출시되었습니다.
StatefulSets는 서로 다른(고유한) 지속적인 ID와 탄력적인 호스트 이름(안정적)을 가진 포드 세트를 나타냅니다. 이를 통해 확장 및 배포 순서를 확인할 수 있습니다. StatefulSet을 이해하기 전에 Kubernetes 배포를 이해해야 합니다.
다음은 web이라는 StatefulSet의 예입니다.
apiVersion: apps/v1 kind: StatefulSet metadata: name: web spec: serviceName: "nginx" replicas: 4 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: registry.k8s.io/nginx-slim:0.8 ports: - containerPort: 80 name: web volumeMounts: - name: www mountPath: /usr/share/nginx/html volumeClaimTemplates: - metadata: name: www spec: accessModes: [ "ReadWriteOnce" ] resources: requests: storage: 1Gi
Kubernetes의 StatefulSet는 안정적이고 고유한 네트워크 식별자, 영구 스토리지, 질서 있고 점진적인 배포 및 확장이 필요한 상태 저장 애플리케이션을 배포하는 데 이상적입니다. 일관된 ID와 저장소가 필요한 데이터베이스, 키-값 저장소, 메시징 대기열과 같은 애플리케이션에 적합합니다.
MongoDB 데이터베이스에 연결된 node.js 애플리케이션을 생각해 보세요. node.js 애플리케이션에 요청이 오면 요청을 독립적으로 처리하며 이를 수행하기 위해 이전 데이터에 의존하지 않습니다. 요청 자체의 페이로드를 기반으로 요청을 처리합니다. 이 node.js 애플리케이션은 Stateless 애플리케이션의 예입니다. 이제 요청은 데이터베이스의 일부 데이터를 업데이트하거나 데이터베이스의 일부 데이터를 쿼리합니다. node.js가 해당 요청을 MongoDB에 전달하면 MongoDB는 데이터의 이전 상태를 기반으로 데이터를 업데이트하거나 스토리지에서 데이터를 쿼리합니다. 각 요청에 대해 데이터를 처리해야 하며 사용 가능한 최신 데이터 또는 상태에 따라 달라지지만 node.js는 데이터 업데이트 또는 쿼리를 위한 통과일 뿐이며 코드만 처리합니다. 따라서 node.js 애플리케이션은 상태 비저장 애플리케이션이어야 하고 MongoDB 애플리케이션은 상태 저장 애플리케이션이어야 합니다.
때때로 상태 비저장 애플리케이션이 상태 저장 애플리케이션에 연결되어 요청을 데이터베이스에 전달합니다. 이는 상태 저장 애플리케이션에 요청을 전달하는 상태 비저장 애플리케이션의 좋은 예입니다.
다음은 StatefulSet 사용 방법과 StatefulSet의 일부 기본 작업에 대한 단계별 튜토리얼입니다.
1단계. StatefulSet 파일을 생성합니다. 다음 명령을 입력하면 됩니다:
apiVersion: apps/v1 kind: StatefulSet metadata: name: web spec: serviceName: "nginx" replicas: 4 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: registry.k8s.io/nginx-slim:0.8 ports: - containerPort: 80 name: web volumeMounts: - name: www mountPath: /usr/share/nginx/html volumeClaimTemplates: - metadata: name: www spec: accessModes: [ "ReadWriteOnce" ] resources: requests: storage: 1Gi
2단계. 코드 편집기에서 이 파일을 열고 다음 코드를 작성합니다.
touch example-statefulset.yaml
3단계. 이제 서비스 파일과 PertantVolumeClaim 파일을 생성해야 합니다.
apiVersion: apps/v1 kind: StatefulSet metadata: name: gfg-example-statefulset annotations: description: "This is an example statefulset" spec: selector: matchLabels: app: nginx serviceName: "gfg-example-service" replicas: 3 # remember this, we will have 3 identical pods running template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx ports: - containerPort: 80 name: web volumeMounts: - name: www mountPath: /usr/share/nginx/html volumes: - name: www persistentVolumeClaim: claimName: myclaim
4단계. 서비스 파일에 다음 코드를 입력하세요.
touch example-service.yaml touch example-persistentVolumeChain.yaml
5단계. PertantVolumeClaim 파일에 다음 코드를 입력합니다.
apiVersion: v1 kind: Service metadata: name: gfg-example-service annotations: description: "this is an example service" labels: app: nginx spec: ports: - port: 80 name: web clusterIP: None selector: app: nginx
이제 변경 사항을 적용해 보겠습니다.
6단계. gfg-example-statefulset을 생성하려면 터미널에 다음 명령을 입력하세요.
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: myclaim spec: accessModes: - ReadWriteMany resources: requests: storage: 8Gi # This means we are requesting for 8 GB of storage
이렇게 하면 gfg-example-statefulset이 생성되며 비슷한 결과를 얻게 됩니다.
이제 터미널에서 다음 명령으로 StatefulSet를 검색하면
kubectl create -f example-statefulset.yaml
목록에서 gfg-example-statefulset을 찾을 수 있습니다.
7단계. gfg-example-service를 생성하려면 터미널에 다음 명령을 입력하세요.
apiVersion: apps/v1 kind: StatefulSet metadata: name: web spec: serviceName: "nginx" replicas: 4 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: registry.k8s.io/nginx-slim:0.8 ports: - containerPort: 80 name: web volumeMounts: - name: www mountPath: /usr/share/nginx/html volumeClaimTemplates: - metadata: name: www spec: accessModes: [ "ReadWriteOnce" ] resources: requests: storage: 1Gi
이렇게 하면 "gfg-example-service"라는 이름의 서비스가 생성됩니다
8단계. 포드와 서비스를 확인해 보겠습니다. 포드 목록을 가져오려면 터미널에 다음 명령을 입력하세요.
touch example-statefulset.yaml
example-stateful-set.yaml 파일에서 3개의 복제본을 정의하여 생성한 3개의 gfg-pod 목록을 얻을 수 있습니다. 비슷한 결과를 얻게 됩니다:
서비스 목록을 확인하려면 터미널에 다음 명령을 입력하세요.
apiVersion: apps/v1 kind: StatefulSet metadata: name: gfg-example-statefulset annotations: description: "This is an example statefulset" spec: selector: matchLabels: app: nginx serviceName: "gfg-example-service" replicas: 3 # remember this, we will have 3 identical pods running template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx ports: - containerPort: 80 name: web volumeMounts: - name: www mountPath: /usr/share/nginx/html volumes: - name: www persistentVolumeClaim: claimName: myclaim
이렇게 하면 비슷한 결과가 나옵니다.
StatefulSet 추가: Kubernetes 클러스터에 StatefulSet를 추가하려면 kubectl create -f [StatefulSet 파일 이름] 명령을 사용하고 [StatefulSet 파일 이름]을 이름으로 바꾸세요. StatefulSet 매니페스트 파일의
touch example-service.yaml touch example-persistentVolumeChain.yaml
StatefulSet 삭제: Kubernetes에서 StatefulSet을 삭제하려면 kubectl delete statefulset [name] 명령을 사용할 수 있습니다. 여기서 [name]은 원하는 StatefulSet의 이름입니다. 삭제합니다.
apiVersion: v1 kind: Service metadata: name: gfg-example-service annotations: description: "this is an example service" labels: app: nginx spec: ports: - port: 80 name: web clusterIP: None selector: app: nginx
StatefulSet 편집: kubectl edit statefulset [name] 명령을 사용하면 편집기를 열어 명령줄에서 직접 StatefulSet의 구성을 수정할 수 있습니다.
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: myclaim spec: accessModes: - ReadWriteMany resources: requests: storage: 8Gi # This means we are requesting for 8 GB of storage
복제본 확장: kubectl scale 명령은 [StatefulSet 이름]이라는 StatefulSet의 복제본 수를 지정된 [복제본 수]로 확장합니다.
kubectl create -f example-statefulset.yaml
9단계. 이제 포드를 확장하고 작동하는지 확인해 보겠습니다. 포드를 6개 포드로 확장하려면 다음 명령을 입력하세요.
kubectl get statefulsets
이렇게 하면 포드가 3개 더 생성되고 포드 수는 이제 6개가 됩니다. 포드 목록을 가져오려면 다음 명령을 입력하세요.
kubectl apply -f example-service.yaml
비슷한 출력을 얻게 됩니다.
10단계. 이제 포드를 3으로 축소해 보겠습니다. 동일한 명령을 입력하려면 복제본 수를 다시 3으로 변경하세요.
kubectl get pods
이제
으로 Pod 목록을 확인하면
kubectl get services
3개의 포드만 실행 중인 것을 볼 수 있습니다.
이러한 방식으로 StatefulSet를 생성하고 확장한 다음 축소할 수도 있습니다. 터미널을 닫기 전에 StatefulSet 및 서비스를 삭제했는지 확인하세요. kubectl의 더 많은 명령을 알아보려면 Kubectl 명령 치트 시트를 참조하세요.
MySQL과 같은 상태 저장 애플리케이션에서는 데이터 불일치를 방지하기 위해 여러 포드가 동시에 데이터를 읽고 쓸 수 없습니다.
한 포드는 데이터 쓰기 및 변경을 담당하는 마스터 포드로 지정되고, 나머지 포드는 데이터 읽기만 허용되는 슬레이브 포드로 지정됩니다.
각 포드에는 자체 데이터 스토리지 복제본이 있어 데이터 격리 및 독립성이 보장됩니다.
마스터 포드가 데이터를 변경할 때 슬레이브 포드가 데이터 스토리지를 업데이트하여 모든 포드가 동일한 데이터 상태를 갖도록 동기화 메커니즘이 사용됩니다.
상태 저장 애플리케이션의 모든 포드 간에 데이터 일관성을 유지하려면 지속적인 동기화가 필요합니다.
예:
MySQL의 마스터 포드 하나와 슬레이브 포드 두 개가 있다고 가정해 보겠습니다. 이제 새 Pod 복제본이 기존 설정에 합류하면 어떻게 될까요? 이제 새 포드도 자체 스토리지를 생성하고 동기화를 처리해야 하기 때문에 먼저 이전 포드의 데이터를 복제한 다음 마스터 포드의 업데이트를 수신하기 위해 지속적인 동기화를 시작합니다. 각 포드에는 동기화된 데이터와 포드 상태를 포함하는 자체 물리적 스토리지에 의해 백업되는 자체 데이터 스토리지(영구 볼륨)가 있기 때문입니다. 각 포드에는 마스터 포드인지 슬레이브 포드인지에 대한 정보와 기타 개별 특성이 포함된 자체 상태가 있습니다. 이 모든 것은 포드 자체 저장소에 저장됩니다. 따라서 포드가 종료되고 영구 포드가 교체되는 경우입니다. 식별자는 스토리지 볼륨이 교체 포드에 다시 연결되는지 확인합니다. 이렇게 하면 클러스터가 충돌하더라도 데이터가 손실되지 않습니다.
이 기사에서는 Kubernetes StatefulSet를 사용하는 방법에 대해 논의했습니다. StatefulSet는 상태 저장 애플리케이션을 배포하는 데 사용되는 Kubenetes 구성 요소입니다. 상태 저장 애플리케이션은 어떤 형태로든 지속적인 상태나 데이터를 유지하는 애플리케이션입니다. 좋은 예는 데이터베이스가 있는 모든 애플리케이션입니다. StatefulSets를 사용하여 상태 저장 애플리케이션을 배포하는 방법에 대해 논의했습니다. 그 후 Stateful 애플리케이션이 어떻게 작동하는지 논의했습니다. 마지막에는 배포가 상태 비저장 애플리케이션을 배포하는 데 사용되고 StatefulSet이 상태 저장 애플리케이션을 배포하는 데 사용된다는 점을 중심으로 기본적으로 이동하는 StatefulSet과 배포의 차이점에 대해 논의했습니다. 몇 가지 FAQ를 언급하며 이 글을 마무리하겠습니다.
Kubernetes에서 볼륨 크기를 늘리려면 스토리지 크기를 변경하여 PVC(PertantVolumeClaim) 사양을 수정해야 합니다. 그런 다음 기본 스토리지 클래스가 동적 프로비저닝을 지원하는 경우 Kubernetes는 새로운 크기 요구 사항을 충족하기 위해 추가 스토리지를 자동으로 프로비저닝합니다.
Kubernetes의 hostPath 볼륨 유형은 Pod 내에서 직접 노드 파일 시스템의 파일이나 디렉터리에 액세스해야 하는 시나리오에 적합합니다. 일반적으로 노드별 리소스에 액세스하거나 동일한 노드에 있는 컨테이너 간에 데이터를 공유하는 데 사용됩니다.
StatefulSet의 PVC(PerciousVolumeClaim)는 개별 Pod에 안정적이고 지속적인 스토리지를 제공하여 Pod를 다시 시작해도 데이터 지속성과 ID를 보장하는 데 사용됩니다. 이와 대조적으로 배포에서는 일반적으로 데이터 지속성이 요구되지 않는 상태 비저장 애플리케이션에 적합한 임시 볼륨을 사용합니다.
기술적으로는 가능하지만 StatefulSet를 사용하여 상태 비저장 애플리케이션을 배포하는 것은 권장되지 않습니다. StatefulSet은 안정적이고 고유한 식별자와 지속적인 저장소가 필요한 상태 저장 애플리케이션을 위해 특별히 설계되었습니다. StatefulSets를 사용하여 상태 비저장 애플리케이션을 배포하면 불필요한 복잡성과 리소스 오버헤드가 발생할 수 있습니다.
애플리케이션의 특정 요구사항에 따라 다릅니다. 상태 비저장 애플리케이션은 관리 및 수평 확장이 더 간단하며, 상태 저장 애플리케이션은 데이터 무결성을 유지하고 데이터베이스나 메시징 시스템과 같은 특정 워크로드에 더 적합합니다.
위 내용은 Kubernetes Statefulset 초보자 가이드의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!