set di repliche di configurazione non è valido o non siamo un membro di essa, in esecuzione in kubernetes

Question

ho postato questo problema da here

Sono in esecuzione MongoDB sharded in un ambiente kubernetes, con 3 cocci, e 3 casi su ogni coccio. per alcuni motivi, l'istanza di mongodb è stata riprogrammata su un'altra macchina.

il problema è quando un'istanza di mongodb è stata ripianificata in un'altra istanza, il suo replica config verrà invalidato. risultante a questo errore di seguito.

  > rs.status() 
      { 
       "state" : 10, 
       "stateStr" : "REMOVED", 
       "uptime" : 2110, 
       "optime" : Timestamp(1448462710, 6), 
       "optimeDate" : ISODate("2015-11-25T14:45:10Z"), 
       "ok" : 0, 
       "errmsg" : "Our replica set config is invalid or we are not a member of it", 
       "code" : 93 
      } 
      > 

Questa è la configurazione

  > rs.config().members 
      [ 
       { 
        "_id" : 0, 
        "host" : "mongodb-shard2-service:27038", 
        "arbiterOnly" : false, 
        "buildIndexes" : true, 
        "hidden" : false, 
        "priority" : 1, 
        "tags" : { 

        }, 
        "slaveDelay" : 0, 
        "votes" : 1 
       }, 
       { 
        "_id" : 1, 
        "host" : "shard2-slave2-service:27039", 
        "arbiterOnly" : false, 
        "buildIndexes" : true, 
        "hidden" : false, 
        "priority" : 1, 
        "tags" : { 

        }, 
        "slaveDelay" : 0, 
        "votes" : 1 
       }, 
       { 
        "_id" : 2, 
        "host" : "shard2-slave1-service:27033", 
        "arbiterOnly" : false, 
        "buildIndexes" : true, 
        "hidden" : false, 
        "priority" : 1, 
        "tags" : { 

        }, 
        "slaveDelay" : 0, 
        "votes" : 1 
       } 
      ] 

e un campione di db.serverStatus() di un'istanza MongoDB riprogrammata

  > db.serverStatus() 
      { 
       "host" : "mongodb-shard2-master-ofgrb", 
       "version" : "3.0.7", 
       "process" : "mongod", 
       "pid" : NumberLong(8), 

spero che sto facendo senso .. perchè, userò questo in produzione dal vivo molto presto .. grazie !!

Answer 1

infine, kubernetes PetSet risolve questo problema. funziona come per magia

Answer 2

Ci scusiamo per il ritardo. Ecco un post che descrive in dettaglio come far apparire MongoDB: https://medium.com/google-cloud/mongodb-replica-sets-with-kubernetes-d96606bd9474#.x197hr2ps

One Service e uno ReplicationController singola replica per istanza è l'attuale approccio per un'applicazione stateful in cui ogni istanza ha bisogno di una stabile identità prevedibile. Con questo approccio, è anche semplice allocare un PersistentVolume per ciascun pod.

Altre soluzioni sono possibili, come l'approccio sidecar mostrato in quell'esempio e il provider di semi personalizzato nell'esempio Cassandra, ma sono un po 'più complessi.

Kubernetes 1.2 fornirà un mezzo per impostare il nome host (come visualizzato dal contenitore) per ciascun pod. Kubernetes 1.3 aggiungerà un nuovo controller per creare le istanze.

Answer 3

Per coloro che desiderano utilizzare il vecchio modo di configurare mongo (utilizzando ReplicationControllers o Deployment anziché PetSet), il problema sembra essere nel ritardo di assegnazione del nome host dei servizi di kubernetes. La soluzione è quella di aggiungere un ritardo di 10 secondi nel entrypoint contenitore (prima di iniziare la mongo reale):

spec: 
    containers: 
    - name: mongo-node1 
     image: mongo 
     command: ["/bin/sh", "-c"] 
     args: ["sleep 10 && mongod --replSet rs1"] 
     ports: 
     - containerPort: 27017 
     volumeMounts: 
     - name: mongo-persistent-storage1 
      mountPath: /data/db 

discussione relativa: https://jira.mongodb.org/browse/SERVER-24778