Eu executo um pequeno cluster do Kubernetes no Azure, portanto, posso usar resumos fornecidos pelo Azure (como armazenamento, etc.).
Nela, tenho um objeto de implantação definido em um arquivo que inclui um pod e vários contêineres: um contêiner de aplicativo, um contêiner mongodb e alguns outros. Um aplicativo executado a partir de sua imagem, que também inclui todo o binário, portanto, só precisa ter acesso ao banco de dados mongo (em segundo plano). O MongoDB armazena seus dados no volume persistente.
Agora vamos imaginar que preciso alterar a imagem do contêiner do aplicativo. Eu mudo o arquivo de definição de implantação e faço kubectl apply -f deplyment.yml , e posso ver os Kubernetes tentando implementar a mudança.
Mas o problema é que ele tenta executar um novo pod em vez do antigo e rotear corretamente o carregamento nele, mas o novo pod não é executado, pois os volumes são montados no pod antigo e não podem ser montados até que o recipiente antigo seja para baixo.
Então esse é o problema. Eu não consigo entender como fazer essas atualizações sem interrupção. O aplicativo não pode ter balanceamento de carga, portanto, não é possível executar várias cópias e atualizá-las uma a uma. E também tenho receio de que, se eu excluir a Implantação (que tentará excluir efetivamente tudo que estiver conectado), os volumes também poderão ser excluídos.
Existe alguma boa abordagem?
Separe seu banco de dados e seu aplicativo.
Os contêineres de aplicativos recebem sua própria implantação e não precisam de armazenamento persistente. Agora você pode atualizar e replicar essa implantação.
Outra implantação (ou StatefulSet) mantém o mongoDB. Isso usa o armazenamento. Mas você raramente precisa atualizar o mongodb, então não haverá interrupções com muita frequência.
Tags mongodb azure kubernetes deployment