zestaw replik config jest nieprawidłowy lub nie jesteśmy jej członkiem, bieganie w kubernetes

Question

Pisałem ten problem od here

Używam sharded MongoDB w środowisku kubernetes, z 3 odłamki i 3 przypadkach na każdy czerep. z pewnych powodów moja instancja mongodb została przełożona na inną maszynę.

Problem polega na tym, że wystąpienie mongodb zostało przełożone na inną instancję, jego numer replica config zostanie unieważniony. wynikające z tego błędu poniżej.

  > 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 
      } 
      > 

to jest config

  > 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 
       } 
      ] 

i próbka db.serverStatus() o zmienić terminu przykład MongoDB

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

Mam nadzieję, że jestem bez sensu .. bo będę używał tego w produkcji na żywo już wkrótce .. dziękuję !!

Answer 1

wreszcie, kubernetes PetSet rozwiązuje ten problem. działa tak jak magia

Answer 2

Przepraszamy za opóźnienie. Tutaj jest post, który opisuje szczegółowo jak wychować MongoDB: https://medium.com/google-cloud/mongodb-replica-sets-with-kubernetes-d96606bd9474#.x197hr2ps

jednej usługi i jednego ReplicationController pojedynczej repliki za przykład jest obecne podejście do stanowej aplikacji, w której każda instancja potrzebuje stabilnego, przewidywalnego tożsamość. Dzięki takiemu podejściu można łatwo przydzielić wartość PersistentVolume dla każdego bloku.

Możliwe są inne rozwiązania, takie jak podejście boczne pokazane w tym przykładzie i niestandardowy dostawca nasion w przykładzie Cassandra, ale są nieco bardziej złożone.

Kubernetes 1.2 zapewni sposób na ustawienie nazwy hosta (zgodnie z kontenerem) dla każdego bloku. Kubernetes 1.3 doda nowy kontroler do utworzenia instancji.

Answer 3

Dla tych, którzy chcą użyć starego sposobu konfigurowania mongo (przy użyciu kontrolerów ReplicationControllers lub Deployments zamiast PetSet), wydaje się, że problem leży w opóźnieniu przypisania nazwy hosta Usług Cubernetes. Rozwiązaniem tego problemu jest dodanie 10 sekund opóźnienia punktu wejścia zbiornika (przed rozpoczęciem właściwego Mongo)

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 

związane dyskusja: https://jira.mongodb.org/browse/SERVER-24778