이 블로그에서는 Amazon EBS를 사용하여 Kubernetes에서 스테이트풀 컨테이너를 생성하는 방법을 보여줍니다. 카우치베이스 서버는 스테이트풀 컨테이너입니다. 즉, 컨테이너의 상태를 함께 가지고 다녀야 합니다. 쿠버네티스에서는 실행되는 가장 작은 원자 단위인
컨테이너는 파드입니다. 따라서 Couchbase Server 컨테이너는 파드로 실행됩니다. 그리고 기본적으로 Couchbase Server에 저장된 모든 데이터는 동일한 호스트에 저장됩니다.
이 수치는 원래 아마존의 Kubernetes 클러스터 및 Couchbase 서비스 노출. 또한 이 그림은 호스트에 로컬로 저장된 스토리지를 보여줍니다.
파드는 임시적이며 다른 호스트에서 다시 시작할 수 있습니다. A 쿠버네티스 볼륨 는 파드 내에서 실행되는 모든 컨테이너보다 오래 지속되며, 컨테이너를 다시 시작할 때 데이터가 보존됩니다. 그러나
파드가 존재하지 않게 되면 볼륨은 더 이상 존재하지 않게 됩니다. 이 문제는 장기간 데이터가 필요한 애플리케이션에 영구적인 클러스터 범위의 스토리지를 제공하는 퍼시스턴트 볼륨으로 해결할 수 있습니다.
영구 볼륨을 만들고 사용하는 과정은 3단계로 이루어집니다:
- 프로비저닝: 관리자가 클러스터의 네트워크 스토리지(예: AWS ElasticBlockStore 볼륨)를 프로비저닝합니다. 이것은 다음과 같이 호출됩니다.
퍼시스턴트 볼륨. - 저장소 요청: 사용자가 다음을 사용하여 파드에 대한 스토리지를 요청합니다. 클레임. 클레임은 리소스 수준(CPU 및 메모리), 특정 크기 및 액세스 모드(예: 읽기/쓰기 1회 또는 쓰기 전용으로 여러 번 마운트 가능)를 지정할 수 있습니다.
이를 다음과 같이 호출합니다.퍼시스턴트 볼륨 클레임. - 클레임 사용: 클레임은 볼륨으로 마운트되고 스토리지를 위해 파드에 사용됩니다.
특히, 이 블로그에서는 AWS ElasticBlockStore를 다음과 같이 사용하는 방법을 보여드립니다. 퍼시스턴트 볼륨를 생성하고 퍼시스턴트 볼륨 클레임를 클릭한 다음 포드에서 청구합니다.
이 블로그의 전체 소스 코드는 여기에서 확인할 수 있습니다: github.com/arun-gupta/couchbase-kubernetes.
AWS Elastic 블록 스토리지 프로비저닝
팔로잉 제한 사항 를 충족해야 합니다. Amazon ElasticBlockStorage가 Kubernetes에서 퍼시스턴트볼륨으로 사용되는 경우:
- 파드가 실행되는 노드는 AWS EC2 인스턴스여야 한다.
- 해당 인스턴스는 EBS 볼륨과 동일한 지역 및 가용성 영역에 있어야 합니다.
- EBS는 볼륨을 마운트하는 단일 EC2 인스턴스만 지원합니다.
AWS Elastic 블록 스토리지를 생성합니다:
|
1 |
aws ec2 create-volume --region us-west-2 --availability-zone us-west-2a --size 5 --volume-type gp2 |
지역 us-west-2 지역 및 US-WEST-2A 가용성 영역이 사용됩니다. 따라서 쿠버네티스 클러스터는 다음을 시작해야 합니다.
를 동일한 지역 및 가용성 영역에서도 사용할 수 있습니다. 출력은 다음과 같이 표시됩니다:
|
1 2 3 4 5 6 7 8 9 10 11 |
{ "AvailabilityZone": "us-west-2a", "Encrypted": false, "VolumeType": "gp2", "VolumeId": "vol-47f59cce", "State": "creating", "Iops": 100, "SnapshotId": "", "CreateTime": "2016-07-29T21:57:43.343Z", "Size": 5 } |
볼륨을 다음과 같이 사용할 수 있는지 확인합니다:
|
1 |
aws --region us-west-2 ec2 describe-volumes --volume-id vol-47f59cce |
출력은 다음과 같이 표시됩니다:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
{ "Volumes": [ { "AvailabilityZone": "us-west-2a", "Attachments": [], "Encrypted": false, "VolumeType": "gp2", "VolumeId": "vol-47f59cce", "State": "available", "Iops": 100, "SnapshotId": "", "CreateTime": "2016-07-29T21:57:43.343Z", "Size": 5 } ] } |
볼륨의 고유 식별자를 VolumeId 속성을 확인합니다. AWS 콘솔에서 EBS 블록을 확인할 수도 있습니다:
쿠버네티스 클러스터 시작
다운로드 쿠버네티스 1.3.3를 클릭하고 압축을 푼 다음 Amazon에서 클러스터를 시작합니다:
|
1 2 |
export KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2a NODE_SIZE=m3.large NUM_NODES=3 ./kubernetes/cluster/kube-up.sh |
여기서 주목해야 할 세 가지 사항이 있습니다:
- 클러스터가 시작되는 영역은 다음과 같이 명시적으로 설정됩니다.
US-WEST-1A. 이는 EBS 스토리지 볼륨이 생성된 영역과 일치합니다. - 기본적으로 각 노드 크기는
m3.medium. 여기서는 다음과 같이 설정되어 있습니다.m3.large. - 기본적으로 마스터 노드 1개와 워커 노드 4개가 생성됩니다. 여기서는 3개의 워커 노드만 생성됩니다.
출력은 다음과 같이 표시됩니다:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 |
... Starting cluster in us-west-2a using provider aws ... calling verify-prereqs ... calling kube-up Starting cluster using os distro: jessie Uploading to Amazon S3 +++ Staging server tars to S3 Storage: kubernetes-staging-0eaf81fbc51209dd47c13b6d8b424149/devel upload: ../../../../../var/folders/81/ttv4n16x7p390cttrm_675y00000gn/T/kubernetes.XXXXXX.ISohbaGM/s3/bootstrap-script to s3://kubernetes-staging-0eaf81fbc51209dd47c13b6d8b424149/devel/bootstrap-script Uploaded server tars: SERVER_BINARY_TAR_URL: https://s3.amazonaws.com/kubernetes-staging-0eaf81fbc51209dd47c13b6d8b424149/devel/kubernetes-server-linux-amd64.tar.gz SALT_TAR_URL: https://s3.amazonaws.com/kubernetes-staging-0eaf81fbc51209dd47c13b6d8b424149/devel/kubernetes-salt.tar.gz BOOTSTRAP_SCRIPT_URL: https://s3.amazonaws.com/kubernetes-staging-0eaf81fbc51209dd47c13b6d8b424149/devel/bootstrap-script INSTANCEPROFILE arn:aws:iam::598307997273:instance-profile/kubernetes-master 2016-07-29T15:13:35Z AIPAJF3XKLNKOXOTQOCTkubernetes-master / ROLES arn:aws:iam::598307997273:role/kubernetes-master 2016-07-29T15:13:33Z / AROAI3Q2KFBD5PCKRXCRM kubernetes-master ASSUMEROLEPOLICYDOCUMENT 2012-10-17 STATEMENT sts:AssumeRole Allow PRINCIPAL ec2.amazonaws.com INSTANCEPROFILE arn:aws:iam::598307997273:instance-profile/kubernetes-minion 2016-07-29T15:13:39Z AIPAIYSH5DJA4UPQIP4Bkubernetes-minion / ROLES arn:aws:iam::598307997273:role/kubernetes-minion 2016-07-29T15:13:37Z / AROAIQ57MPQYSHRPQCT2Q kubernetes-minion ASSUMEROLEPOLICYDOCUMENT 2012-10-17 STATEMENT sts:AssumeRole Allow PRINCIPAL ec2.amazonaws.com Using SSH key with (AWS) fingerprint: SHA256:dX/5wpWuUxYar2NFuGwiZuRiydiZCyx4DGoZ5/jL/j8 Creating vpc. Adding tag to vpc-fa3d6c9e: Name=kubernetes-vpc Adding tag to vpc-fa3d6c9e: KubernetesCluster=kubernetes Using VPC vpc-fa3d6c9e Adding tag to dopt-3aad625e: Name=kubernetes-dhcp-option-set Adding tag to dopt-3aad625e: KubernetesCluster=kubernetes Using DHCP option set dopt-3aad625e Creating subnet. Adding tag to subnet-e11f5985: KubernetesCluster=kubernetes Using subnet subnet-e11f5985 Creating Internet Gateway. Using Internet Gateway igw-5c748f38 Associating route table. Creating route table Adding tag to rtb-84fcf1e0: KubernetesCluster=kubernetes Associating route table rtb-84fcf1e0 to subnet subnet-e11f5985 Adding route to route table rtb-84fcf1e0 Using Route Table rtb-84fcf1e0 Creating master security group. Creating security group kubernetes-master-kubernetes. Adding tag to sg-91590bf7: KubernetesCluster=kubernetes Creating minion security group. Creating security group kubernetes-minion-kubernetes. Adding tag to sg-9d590bfb: KubernetesCluster=kubernetes Using master security group: kubernetes-master-kubernetes sg-91590bf7 Using minion security group: kubernetes-minion-kubernetes sg-9d590bfb Creating master disk: size 20GB, type gp2 Adding tag to vol-def79e57: Name=kubernetes-master-pd Adding tag to vol-def79e57: KubernetesCluster=kubernetes Allocated Elastic IP for master: 52.40.216.69 Adding tag to vol-def79e57: kubernetes.io/master-ip=52.40.216.69 Generating certs for alternate-names: IP:52.40.216.69,IP:172.20.0.9,IP:10.0.0.1,DNS:kubernetes,DNS:kubernetes.default,DNS:kubernetes.default.svc,DNS:kubernetes.default.svc.cluster.local,DNS:kubernetes-master Starting Master Adding tag to i-5a7cebf5: Name=kubernetes-master Adding tag to i-5a7cebf5: Role=kubernetes-master Adding tag to i-5a7cebf5: KubernetesCluster=kubernetes Waiting for master to be ready Attempt 1 to check for master nodeWaiting for instance i-5a7cebf5 to be running (currently pending) Sleeping for 3 seconds... Waiting for instance i-5a7cebf5 to be running (currently pending) Sleeping for 3 seconds... Waiting for instance i-5a7cebf5 to be running (currently pending) Sleeping for 3 seconds... Waiting for instance i-5a7cebf5 to be running (currently pending) Sleeping for 3 seconds... [master running] Attaching IP 52.40.216.69 to instance i-5a7cebf5 Attaching persistent data volume (vol-def79e57) to master 2016-07-29T22:00:36.909Z /dev/sdb i-5a7cebf5 attaching vol-def79e57 cluster "aws_kubernetes" set. user "aws_kubernetes" set. context "aws_kubernetes" set. switched to context "aws_kubernetes". user "aws_kubernetes-basic-auth" set. Wrote config for aws_kubernetes to /Users/arungupta/.kube/config Creating minion configuration Creating autoscaling group 0 minions started; waiting 0 minions started; waiting 0 minions started; waiting 0 minions started; waiting 3 minions started; ready Waiting for cluster initialization. This will continually check to see if the API for kubernetes is reachable. This might loop forever if there was some uncaught error during start up. ..........................................................................................................................................................................................................Kubernetes cluster created. Sanity checking cluster... Attempt 1 to check Docker on node @ 52.42.0.65 ...not working yet Attempt 2 to check Docker on node @ 52.42.0.65 ...not working yet Attempt 3 to check Docker on node @ 52.42.0.65 ...working Attempt 1 to check Docker on node @ 52.36.195.201 ...working Attempt 1 to check Docker on node @ 52.43.35.173 ...working Kubernetes cluster is running. The master is running at: https://52.40.216.69 The user name and password to use is located in /Users/arungupta/.kube/config. ... calling validate-cluster Found 3 node(s). NAME STATUS AGE ip-172-20-0-26.us-west-2.compute.internal Ready 1m ip-172-20-0-27.us-west-2.compute.internal Ready 1m ip-172-20-0-28.us-west-2.compute.internal Ready 1m Validate output: NAME STATUS MESSAGE ERROR controller-manager Healthy ok scheduler Healthy ok etcd-0 Healthy {"health": "true"} etcd-1 Healthy {"health": "true"} Cluster validation succeeded Done, listing cluster services: Kubernetes master is running at https://52.40.216.69 Elasticsearch is running at https://52.40.216.69/api/v1/proxy/namespaces/kube-system/services/elasticsearch-logging Heapster is running at https://52.40.216.69/api/v1/proxy/namespaces/kube-system/services/heapster Kibana is running at https://52.40.216.69/api/v1/proxy/namespaces/kube-system/services/kibana-logging KubeDNS is running at https://52.40.216.69/api/v1/proxy/namespaces/kube-system/services/kube-dns kubernetes-dashboard is running at https://52.40.216.69/api/v1/proxy/namespaces/kube-system/services/kubernetes-dashboard Grafana is running at https://52.40.216.69/api/v1/proxy/namespaces/kube-system/services/monitoring-grafana InfluxDB is running at https://52.40.216.69/api/v1/proxy/namespaces/kube-system/services/monitoring-influxdb To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'. |
시작에 대한 자세한 내용을 읽어보세요. 아마존의 쿠버네티스 클러스터.
퍼시스턴트 스토리지가 없는 카우치베이스 서버 포드
영구 저장소가 없는 Couchbase Server 파드를 생성해 보겠습니다. 즉, 다른 호스트에서 파드를 다시 스케줄링하면 해당 호스트에서 생성된 데이터에 액세스할 수 없습니다. 다음은 Couchbase Server 포드를 실행하는 빠른 단계입니다.
클러스터 외부에 노출합니다:
|
1 2 3 |
kubectl.sh run couchbase --image=arungupta/couchbase kubectl.sh expose deployment couchbase --target-port=8091 --port=8091 --type=LoadBalancer kubectl.sh describe svc couchbase |
자세한 내용은 다음에서 확인하세요. 아마존의 쿠버네티스 클러스터. 마지막 명령은 인그레스 로드 밸런서 주소를 표시합니다. 다음 주소에서 Couchbase Server 웹 콘솔에 액세스합니다. :8091.
다음을 사용하여 콘솔에 로그인합니다. 관리자 로그인 및 비밀번호 비밀번호를 입력합니다. 카우치베이스 서버 웹 콘솔의 메인 페이지가 표시됩니다:
기본값 여행 샘플 버킷은 이미 아룽업타/카우치베이스 이미지. 이 버킷은 데이터 버킷 탭을 클릭합니다:
를 클릭합니다. 새 데이터 버킷 만들기 버튼을 클릭하여 새 데이터 버킷을 만듭니다. 이름 지정 k8s를 클릭하고 모든 기본값을 선택한 다음 만들기 버튼을 눌러 버킷을 생성합니다:
생성된 버킷은 데이터 버킷 탭을 클릭합니다:
포드 상태를 확인합니다:
|
1 2 3 |
kubectl.sh get po NAME READY STATUS RESTARTS AGE couchbase-2646907196-memz2 1/1 Running 0 53m |
포드를 삭제합니다:
|
1 2 |
kubectl.sh delete po couchbase-2646907196-memz2 pod "couchbase-2646907196-memz2" deleted |
새 포드가 생성되는 과정을 지켜보세요:
|
1 2 3 4 |
kubectl.sh get -w po NAME READY STATUS RESTARTS AGE couchbase-2646907196-memz2 1/1 Terminating 0 53m couchbase-2646907196-wo6ve 1/1 Running 0 3s |
웹 콘솔에 다시 액세스하여 버킷이 존재하지 않는지 확인합니다:
생성된 리소스를 정리해 보겠습니다:
|
1 2 |
kubectl.sh delete svc couchbase kubectl.sh delete deployment couchbase |
퍼시스턴트 스토리지가 있는 Couchbase 서버 포드
이제 퍼시스턴트 스토리지가 있는 Couchbase Server 포드를 노출해 보겠습니다. 위에서 설명한 대로 퍼시스턴트 볼륨 를 클릭하고 볼륨을 청구하세요.
저장소 요청
다른 쿠버네티스 리소스와 마찬가지로, 퍼시스턴트 볼륨은 리소스 설명 파일을 사용하여 생성됩니다:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
kind: PersistentVolume apiVersion: v1 metadata: name: couchbase-pv labels: type: amazonEBS spec: capacity: storage: 5Gi accessModes: - ReadWriteOnce awsElasticBlockStore: volumeID: vol-47f59cce fsType: ext4 |
여기서 중요한 정보는 다음과 같습니다:
- 5GB의 스토리지 만들기
- 읽기/쓰기를 위해 하나의 노드만 스토리지를 마운트할 수 있습니다.
- 이전에 생성된 볼륨 ID를 지정합니다.
이 파일의 정의에 대한 자세한 내용은 다음에서 확인하세요. kubernetes.io/docs/user-guide/persistent-volumes/. 이 파일은 다음에서 사용할 수 있습니다: github.com/arun-gupta/couchbase-kubernetes/blob/master/pv/couchbase-pv.yml.
볼륨 자체는 다음과 같이 만들 수 있습니다:
|
1 |
kubectl create -f couchbase-pv.yml |
를 클릭하고 출력을 표시합니다:
|
1 |
persistentvolume "couchbase-pv" created |
클레임 사용
A 퍼시스턴트 볼륨 클레임 이 리소스 파일을 사용하여 만들 수 있습니다:
|
1 2 3 4 5 6 7 8 9 10 11 12 |
kind: PersistentVolumeClaim apiVersion: v1 metadata: name: couchbase-pvc labels: type: amazonEBS spec: accessModes: - ReadWriteOnce resources: requests: storage: 5Gi |
이 경우 PersistentVolume과 PersistentVolumeClaim은 모두 5GB이지만 반드시 그럴 필요는 없습니다. 이 파일의 정의에 대한 자세한 내용은 다음에서 확인하세요. 쿠버네티스 문서/사용자 가이드/퍼시스턴트 볼륨/#퍼시스턴트 볼륨 클레임.
이 파일은 다음 위치에 있습니다. github.com/arun-gupta/couchbase-kubernetes/blob/master/pv/couchbase-pvc.yml. 클레임은 다음과 같이 만들 수 있습니다:
|
1 |
kubectl create -f couchbase-pvc.yml |
를 클릭하고 출력을 표시합니다:
|
1 |
persistentvolumeclaim "couchbase-pvc" created |
영구 볼륨 클레임으로 RC 생성
이 리소스 파일을 사용하여 카우치베이스 복제 컨트롤러를 생성합니다:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 |
apiVersion: v1 kind: ReplicationController metadata: name: couchbase spec: replicas: 1 template: metadata: name: couchbase-rc-pod labels: name: couchbase-rc-pod context: couchbase-pv spec: containers: - name: couchbase-rc-pod image: arungupta/couchbase volumeMounts: - mountPath: "/opt/couchbase/var" name: mypd ports: - containerPort: 8091 - containerPort: 8092 - containerPort: 8093 - containerPort: 11210 volumes: - name: mypd persistentVolumeClaim: claimName: couchbase-pvc |
여기서 중요한 부분은 다음과 같습니다:
- 리소스는 다음을 사용하여 복제 컨트롤러를 정의합니다.
아룽업타/카우치베이스도커 이미지 볼륨 마운트마운트할 볼륨을 정의합니다./opt/couchbase/var는 Couchbase Server가 모든 데이터를 저장하는 디렉터리입니다.볼륨이 RC 정의에서 사용할 수 있는 다른 볼륨을 정의합니다.
RC를 다음과 같이 만듭니다:
|
1 |
kubectl create -f couchbase-rc.yml |
를 클릭하고 출력을 표시합니다:
|
1 |
replicationcontroller "couchbase" created |
파드가 다음과 같은지 확인합니다. kubectl.sh get -w po 를 클릭합니다:
|
1 2 3 4 5 |
kubectl.sh get -w po NAME READY STATUS RESTARTS AGE couchbase-jx3fn 0/1 ContainerCreating 0 3s NAME READY STATUS RESTARTS AGE couchbase-jx3fn 1/1 Running 0 20s |
RC를 서비스로 노출하세요:
|
1 2 |
kubectl.sh expose rc couchbase --target-port=8091 --port=809--type=LoadBalancer service "couchbase" exposed |
모든 서비스를 이용하세요:
|
1 2 3 4 |
kubectl.sh get svc NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE couchbase 10.0.49.129 a6179426155e2... 8091/TCP 19s kubernetes 10.0.0.1 443/TCP 1h |
서비스를 다음과 같이 설명합니다. kubectl.sh 설명 svc 카우치베이스 를 클릭합니다:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
Name: couchbase Namespace: default Labels: context=couchbase-pv name=couchbase-pod Selector: context=couchbase-pv,name=couchbase-pod Type: LoadBalancer IP: 10.0.49.129 LoadBalancer Ingress: a6179426155e211e6b664022b850255f-1850736155.us-west-2.elb.amazonaws.com Port: 8091/TCP NodePort: 31636/TCP Endpoints: 10.244.1.3:8091 Session Affinity: None Events: FirstSeen LastSeen Count From SubobjectPath Type Reason Message --------- -------- ----- ---- ------------- -------- ------ ------- 31s 31s 1 {service-controller } Normal CreatingLoadBalancer Creating load balancer 29s 29s 1 {service-controller } Normal CreatedLoadBalancer Created load balancer |
로드 밸런서가 안정화될 때까지 약 3분 정도 기다립니다. 다음 주소에서 Couchbase Server 웹 콘솔에 액세스합니다. :8091. 다시 한 번 강조하지만 여행 샘플 버킷이 존재합니다. 이 버킷은 다음에 의해 생성됩니다. 아룽업타/카우치베이스 이미지가 사용됩니다.
스테이트풀 컨테이너 표시
새 버킷을 만들어 보겠습니다. 이름 지정하기 쿠버네티스-pv를 클릭하고 모든 기본값을 설정한 후 만들기 버튼을 클릭하여 버킷을 생성합니다.
이제 버킷이 콘솔에 표시됩니다:
카우치베이스 서버 파드를 종료하고 상태가 복원되는 것을 확인합니다. 파드를 다시 가져옵니다:
|
1 2 3 |
kubectl.sh get po NAME READY STATUS RESTARTS AGE couchbase-jx3fn 1/1 Running 0 7m |
포드를 삭제합니다:
|
1 2 |
kubectl.sh delete po couchbase-jx3fn pod "couchbase-jx3fn" deleted |
파드가 다시 생성됩니다:
|
1 2 3 4 5 6 |
kubectl.sh get -w po NAME READY STATUS RESTARTS AGE couchbase-jx3fn 1/1 Terminating 0 8m couchbase-qq6wu 0/1 ContainerCreating 0 4s NAME READY STATUS RESTARTS AGE couchbase-qq6wu 1/1 Running 0 5s |
이제 Couchbase 웹 콘솔에 액세스하면 이전에 생성한 버킷이 여전히 존재합니다:
이는 데이터가 EBS 백업 스토리지에 저장되어 있었기 때문입니다.
쿠버네티스 클러스터 정리
쿠버네티스 클러스터를 종료합니다:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 |
KUBE_AWS_ZONE=us-west-2a NODE_SIZE=m3.large NUM_NODES=3 ./kubernetes/cluster/kube-down.sh Bringing down cluster using provider: aws Deleting ELBs in: vpc-fa3d6c9e Waiting for ELBs to be deleted All ELBs deleted Deleting instances in VPC: vpc-fa3d6c9e Deleting auto-scaling group: kubernetes-minion-group-us-west-2a Deleting auto-scaling launch configuration: kubernetes-minion-group-us-west-2a Deleting auto-scaling group: kubernetes-minion-group-us-west-2a Deleting auto-scaling group: kubernetes-minion-group-us-west-2a Waiting for instances to be deleted Waiting for instance i-8b7aed24 to be terminated (currently shutting-down) Sleeping for 3 seconds... Waiting for instance i-8b7aed24 to be terminated (currently shutting-down) Sleeping for 3 seconds... Waiting for instance i-8b7aed24 to be terminated (currently shutting-down) Sleeping for 3 seconds... Waiting for instance i-8b7aed24 to be terminated (currently shutting-down) Sleeping for 3 seconds... Waiting for instance i-8b7aed24 to be terminated (currently shutting-down) Sleeping for 3 seconds... Waiting for instance i-8b7aed24 to be terminated (currently shutting-down) Sleeping for 3 seconds... Waiting for instance i-8b7aed24 to be terminated (currently shutting-down) Sleeping for 3 seconds... Waiting for instance i-8b7aed24 to be terminated (currently shutting-down) Sleeping for 3 seconds... Waiting for instance i-8b7aed24 to be terminated (currently shutting-down) Sleeping for 3 seconds... Waiting for instance i-8b7aed24 to be terminated (currently shutting-down) Sleeping for 3 seconds... Waiting for instance i-8b7aed24 to be terminated (currently shutting-down) Sleeping for 3 seconds... Waiting for instance i-8b7aed24 to be terminated (currently shutting-down) Sleeping for 3 seconds... Waiting for instance i-8b7aed24 to be terminated (currently shutting-down) Sleeping for 3 seconds... Waiting for instance i-8b7aed24 to be terminated (currently shutting-down) Sleeping for 3 seconds... Waiting for instance i-8b7aed24 to be terminated (currently shutting-down) Sleeping for 3 seconds... Waiting for instance i-8b7aed24 to be terminated (currently shutting-down) Sleeping for 3 seconds... Waiting for instance i-8b7aed24 to be terminated (currently shutting-down) Sleeping for 3 seconds... Waiting for instance i-8b7aed24 to be terminated (currently shutting-down) Sleeping for 3 seconds... Waiting for instance i-8b7aed24 to be terminated (currently shutting-down) Sleeping for 3 seconds... All instances deleted Releasing Elastic IP: 52.40.216.69 Deleting volume vol-def79e57 Cleaning up resources in VPC: vpc-fa3d6c9e Cleaning up security group: sg-91590bf7 Cleaning up security group: sg-9d590bfb Cleaning up security group: sg-e97b298f Deleting security group: sg-91590bf7 Deleting security group: sg-9d590bfb Deleting security group: sg-e97b298f Deleting VPC: vpc-fa3d6c9e Done |
그리고 볼륨을 분리합니다:
|
1 |
aws ec2 delete-volume --region us-west-2 --volume-id vol-47f59cce |
이 블로그의 전체 소스 코드는 여기에서 확인할 수 있습니다: github.com/arun-gupta/couchbase-kubernetes.
즐기세요!
좋은 기사입니다. 정리해 주셔서 감사합니다.
이 예제는 단일 AZ에 대한 가정이 명확하게 명시되어 있습니다. 하지만 실제 프로덕션 환경에서는 여러 AZ에 걸쳐 k8s 클러스터를 배포해야 하며, 이는 다음과 같이 매우 쉽습니다.
kops. 이로 인해 PV 배포에 여러 가지 문제가 발생합니다. 이를 수행하는 방법에 대한 좋은 예를 찾을 수 없었습니다. 혹시 알고 계신 예가 있으신가요? 아니면 여러 AZ를 지원하도록 이 예제를 업데이트할 의향이 있으신가요?k8s 문서를 읽으면 각 AZ에 대해 StorageClass 리소스를 사용해야 하는 것으로 보입니다.
퍼시스턴트 볼륨클래스에 추가하고 싶지만배포(또는 ReplicationController)를 사용하여 올바른StorageClass노드에서 해당 장소가 예약되기 전까지는 알 수 없는 AZ를 기반으로 합니다.또한
여행 샘플는 두 번 모두 저에게 나타나지 않았습니다. 그리고 두 번째kubectl.sh expose rc couchbase --target-port=8091 --port=809-- type=LoadBalancer는kubectl expose rc couchbase --target-port=8091 --port=8091 --type=LoadBalancer다음을 사용하도록 업데이트하는 것도 흥미로울 수 있습니다.
kops(또는 이에 대한 다른 훌륭한 기사를 참조하세요) 그리고복제 컨트롤러와 함께배포.이에 대한 해결책을 찾았나요? PV로 CB 클러스터를 생성하려고 시도하고 있습니다. 처음 시작할 때는 모두 작동하는 것 같지만 일단 CD 파드를 죽이면 새 파드가 더 이상 CB 클러스터에 가입 할 수없고 IP가 차단 된 것 같고 CB 마스터 파드가 새 워커에 다시 연결할 수 없습니다.
건배