Este blog mostrará cómo crear contenedores con estado en Kubernetes utilizando Amazon EBS. Couchbase Server es un contenedor con estado. Esto significa que el estado del contenedor necesita ser transportado con él. En Kubernetes, la unidad atómica más pequeña de ejecución
un contenedor es un pod. Así que un contenedor de Couchbase Server se ejecutará como un pod. Y por defecto, todos los datos almacenados en Couchbase Server se almacenan en el mismo host.
Esta cifra se explica originalmente en Clúster Kubernetes en Amazon y exponer el servicio Couchbase. Además, esta figura muestra el almacenamiento local del host.
Los pods son efímeros y pueden reiniciarse en un host diferente. A Volumen Kubernetes sobrevive a cualquier contenedor que se ejecute dentro del pod, y los datos se conservan a través de reinicios del contenedor. Sin embargo,
el volumen dejará de existir cuando un pod deje de existir. Esto se soluciona con los volúmenes persistentes, que proporcionan almacenamiento persistente en clústeres para aplicaciones que requieren datos de larga duración.
- Provisión: El administrador aprovisiona un almacenamiento en red en el clúster, como los volúmenes de AWS ElasticBlockStore. Esto se denomina
Volumen persistente. - Solicitar almacenamiento: El usuario solicita almacenamiento para pods utilizando reclamaciones. Las reclamaciones pueden especificar niveles de recursos (CPU y memoria), tamaños específicos y modos de acceso (por ejemplo, se puede montar una vez lectura/escritura o muchas veces sólo escritura).
Esto se denominaPersistentVolumeClaim. - Reclamación de uso: Las reclamaciones se montan como volúmenes y se utilizan en pods para el almacenamiento.
En concreto, este blog mostrará cómo utilizar un AWS ElasticBlockStore como Volumen persistentecrear un PersistentVolumeClaimy luego reclamarla en una vaina.
El código fuente completo de este blog está en: github.com/arun-gupta/couchbase-kubernetes.
Aprovisionar AWS Elastic Block Storage
Después de restricciones si se utiliza Amazon ElasticBlockStorage como PersistentVolume con Kubernetes:
- los nodos en los que se ejecutan los pods deben ser instancias AWS EC2
- esas instancias deben estar en la misma región y zona de disponibilidad que el volumen EBS
- EBS sólo admite una única instancia EC2 montando un volumen
Crear un AWS Elastic Block Storage:
|
1 |
aws ec2 create-volume --region us-west-2 --availability-zone us-west-2a --size 5 --volume-type gp2 |
La región us-oeste-2 región y us-oeste-2a zona de disponibilidad se utiliza aquí. Y así Kubernetes clúster necesita para iniciar
en la misma región y zona de disponibilidad. Esto muestra la salida como:
|
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 } |
Compruebe si el volumen está disponible como:
|
1 |
aws --region us-west-2 ec2 describe-volumes --volume-id vol-47f59cce |
Muestra la salida como:
|
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 } ] } |
Anote el identificador único del volumen en VolumeId atributo. También puede verificar el bloque EBS en la consola de AWS:
Iniciar clúster Kubernetes
Descargar Kubernetes 1.3.3Descomprímelo e inicia el clúster en 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 |
Tres puntos a tener en cuenta aquí:
- La zona en la que se inicia el clúster se establece explícitamente en
us-oeste-1a. Coincide con la zona en la que se creó el volumen de almacenamiento EBS. - Por defecto, el tamaño de cada nodo es
m3.medio. Aquí está ajustado am3.grande. - Por defecto, se crean 1 nodo maestro y 4 nodos trabajadores. Aquí sólo se crean 3 nodos trabajadores.
Esto mostrará la salida como:
|
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'. |
Más información sobre Clúster Kubernetes en Amazon.
Couchbase Server Pod sin almacenamiento persistente
Vamos a crear un pod de Couchbase Server sin almacenamiento persistente. Esto significa que si el pod es reprogramado en un host diferente entonces no tendrá acceso a los datos creados en él. Aquí están los pasos rápidos para ejecutar un pod de Couchbase Server y
exponerlo fuera del clúster:
|
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 |
Más información en Clúster Kubernetes en Amazon. El último comando muestra la dirección del equilibrador de carga de entrada. Acceda a la consola web del servidor Couchbase en :8091.
Inicie sesión en la consola mediante Administrador inicio de sesión y contraseña contraseña. Aparecerá la página principal de la Consola Web del Servidor Couchbase:
Un defecto viaje-muestra ya está creado por arungupta/couchbase imagen. Este cubo se muestra en el Cubos de datos ficha:
Haga clic en Crear nuevo cubo de datos para crear un nuevo cubo de datos. Déle un nombre k8s, tome todos los valores predeterminados y haga clic en Cree para crear el cubo:
El cubo creado se muestra en el Cubos de datos ficha:
Compruebe el estado del pod:
|
1 2 3 |
kubectl.sh get po NAME READY STATUS RESTARTS AGE couchbase-2646907196-memz2 1/1 Running 0 53m |
Elimine la cápsula:
|
1 2 |
kubectl.sh delete po couchbase-2646907196-memz2 pod "couchbase-2646907196-memz2" deleted |
Observa cómo se crea la nueva cápsula:
|
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 |
Acceda de nuevo a la Consola Web y compruebe que el cubo no existe:
Limpiemos los recursos creados:
|
1 2 |
kubectl.sh delete svc couchbase kubectl.sh delete deployment couchbase |
Couchbase Server Pod con almacenamiento persistente
Ahora, vamos a exponer un pod de Couchbase Server con almacenamiento persistente. Como ya hemos comentado, vamos a crear un pod Volumen persistente y reclamar el volumen.
Solicitar almacenamiento
Como cualquier otro recurso de Kubernetes, un volumen persistente se crea utilizando un archivo de descripción de recursos:
|
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 |
Los datos importantes son los siguientes:
- Crear un almacenamiento de 5 GB
- El almacenamiento sólo puede ser montado por un nodo para lectura/escritura
- especifica el identificador de volumen creado anteriormente
Más información sobre la definición de este archivo en kubernetes.io/docs/user-guide/persistent-volumes/. Este archivo está disponible en: github.com/arun-gupta/couchbase-kubernetes/blob/master/pv/couchbase-pv.yml.
El volumen en sí se puede crear como:
|
1 |
kubectl create -f couchbase-pv.yml |
y muestra la salida:
|
1 |
persistentvolume "couchbase-pv" created |
Reclamación de uso
A PersistentVolumeClaim pueden crearse utilizando este archivo de recursos:
|
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 |
En nuestro caso, tanto PersistentVolume como PersistentVolumeClaim son de 5 GB, pero no tienen por qué serlo. Lea más detalles sobre la definición de este fichero en kubernetes.io/docs/user-guide/persistent-volumes/#persistentvolumeclaims.
Este archivo se encuentra en github.com/arun-gupta/couchbase-kubernetes/blob/master/pv/couchbase-pvc.yml. La reclamación puede crearse como:
|
1 |
kubectl create -f couchbase-pvc.yml |
y muestra la salida:
|
1 |
persistentvolumeclaim "couchbase-pvc" created |
Crear RC con reclamación de volumen persistente
Cree un controlador de replicación Couchbase utilizando este archivo de recursos:
|
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 |
Las partes clave aquí son:
- El recurso define un controlador de replicación utilizando
arungupta/couchbaseImagen Docker volumeMountsdefinir qué volúmenes se van a montar./opt/couchbase/vares el directorio donde Couchbase Server almacena todos los datos.volúmenesdefinir los diferentes volúmenes que pueden utilizarse en esta definición de CR
Crea el CR como:
|
1 |
kubectl create -f couchbase-rc.yml |
y muestra la salida:
|
1 |
replicationcontroller "couchbase" created |
Compruebe si la vaina es kubectl.sh get -w po para ver:
|
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 |
Exponer RC como un servicio:
|
1 2 |
kubectl.sh expose rc couchbase --target-port=8091 --port=809--type=LoadBalancer service "couchbase" exposed |
Consigue todos los servicios:
|
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 |
Describa el servicio como kubectl.sh describe svc couchbase para ver:
|
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 |
Espere unos 3 minutos a que el equilibrador de carga se asiente. Accede a la consola web de Couchbase Server en :8091. Una vez más, sólo viaje-muestra existe. Se crea mediante arungupta/couchbase imagen utilizada en la definición RC.
Mostrar contenedores con estado
Vamos a crear un nuevo cubo. Dale un nombre kubernetes-pv, tome todos los valores predeterminados y haga clic en el botón Crear para crear el cubo.
El cubo aparece ahora en la consola:
Finalice el pod de Couchbase Server y vea cómo se restaura el estado. Obtenga los pods de nuevo:
|
1 2 3 |
kubectl.sh get po NAME READY STATUS RESTARTS AGE couchbase-jx3fn 1/1 Running 0 7m |
Elimine la cápsula:
|
1 2 |
kubectl.sh delete po couchbase-jx3fn pod "couchbase-jx3fn" deleted |
Pod se recrea:
|
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 |
Y ahora cuando accedes a la Consola Web de Couchbase, el bucket creado anteriormente sigue existiendo:
Esto se debe a que los datos se almacenaron en el almacenamiento EBS de respaldo.
Limpieza del clúster Kubernetes
Apague el clúster Kubernetes:
|
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 |
Y separa el volumen:
|
1 |
aws ec2 delete-volume --region us-west-2 --volume-id vol-47f59cce |
El código fuente completo de este blog está en: github.com/arun-gupta/couchbase-kubernetes.
¡Que aproveche!
Buen artículo. Gracias por redactarlo.
Una suposición clara es que el ejemplo era para una sola AZ. Pero para el uso real de producción, usted querrá desplegar su clúster k8s a través de múltiples AZs, que es bastante fácil con
kops. Esto dificulta en gran medida el despliegue de las instalaciones fotovoltaicas. No he podido encontrar buenos ejemplos de cómo hacerlo. ¿Conoce alguno? ¿O tal vez estén dispuestos a actualizar este ejemplo para soportar múltiples AZs?Leyendo la documentación de k8s parece que tendríamos que utilizar un recurso StorageClass para cada AZ, marcar la opción
VolumenPersistentea la clase, pero no puedo averiguar cómo obtener unDespliegue(o ReplicationController) para elegir el correctoStorageClassen función de la AZ en la que se encuentre, que no se conoce hasta que se programa el lugar en un Nodo.Además, el
viaje-muestrano me apareció ninguna de las dos veces, no es que sea importante. Y la segundakubectl.sh expose rc couchbase --target-port=8091 --port=809--type=LoadBalancerdebe serkubectl expose rc couchbase --target-port=8091 --port=8091 --type=LoadBalancerTambién podría ser interesante actualizarlo para utilizar
kops(o haga referencia a su otro gran artículo sobre cómo hacerlo) y reemplaceReplicationControllerconDespliegue.¿Has encontrado una solución para esto? He estado tratando de crear un clúster CB con PVs. Todo parece funcionar la primera vez que se inician, pero una vez que mato a un pod cd el nuevo pod no puede unirse al clúster CB más, su ip parece estar bloqueado y el pod CB maestro no puede conectarse de nuevo el nuevo trabajador.
Saludos