Crie seu cluster Kubernetes.Continue no controle.

Você fornece os hosts no seu provedor, datacenter ou laboratório. O KubeRocks organiza a configuração, verifica os requisitos e conduz os fluxos de instalação e operação disponíveis para esse ambiente.

Custos e responsabilidades de máquinas, rede, discos, DNS e serviços externos continuam com você. A assinatura proposta é do software, não de infraestrutura gerenciada.

O fluxo desktop atual é voltado a Windows e utiliza Docker local para a execução. Os hosts precisam de conectividade, credenciais e permissões compatíveis com a instalação.

Access & Readiness verifica requisitos do sistema, acesso, CPU, memória, disco e rede. O sistema operacional precisa estar na matriz suportada; um host alcançável por SSH ainda pode não estar apto para o cluster.

Não com os limites propostos. Free admite até 5 nodes, 20 vCPU e 40 GB de RAM, simultaneamente, no agregado da organização. O perfil Prod exige pelo menos 3 control planes e 3 workers: seis nodes Kubernetes, além dos dois hosts HAProxy e da VIP.

Um plano pago com capacidade suficiente pode acomodar essa necessidade comercial, mas não muda os requisitos técnicos nem garante a disponibilidade das aplicações.

Você percorre as decisões relevantes do stepper e seleciona os componentes necessários ao seu cenário. O fluxo contém 11 etapas fixas; HAProxy / Load Balancer aparece quando o perfil exige.

Componentes opcionais não precisam ser ativados em conjunto. Algumas escolhas criam dependências de storage, coleta ou capacidade que precisam ser satisfeitas antes da execução.

As verificações procuram impedimentos conhecidos antes da instalação e conferem condições do Kubernetes depois dela. Falhas obrigatórias bloqueiam o avanço e os resultados ajudam a localizar o problema.

Conectividade, disponibilidade de imagens, estado dos hosts e configuração das aplicações ainda influenciam o resultado. Não existe garantia de zero falhas ou duração fixa para qualquer ambiente.

As credenciais de infraestrutura ficam criptografadas no dispositivo pelo desktop. O serviço central trabalha com referências e dados operacionais sanitizados, sem precisar guardar os segredos do cofre local.

Conexões autorizadas usam o material de autenticação e podem exigir arquivos temporários locais com acesso restrito. Proteja a sessão do sistema operacional e o dispositivo que contém essas credenciais.

Não. Autenticação, serviços centrais, sincronização e download de componentes podem exigir rede, além da conexão com seus hosts e clusters.

Credenciais locais descrevem onde os segredos são protegidos; não significam que todos os dados e todas as funções permanecem desconectados.

Rook-Ceph exige discos elegíveis em pelo menos três workers no fluxo atual. Confira dispositivo, capacidade e estado: a inicialização pode apagar os discos selecionados, com confirmação específica quando existem dados ou assinaturas.

Mantenha backups independentes. Velero exige destino, bucket, credenciais e política adequados; preparar o controlador ou o armazenamento não comprova recuperação. Valide um teste de restauração no seu cenário.

A tela de planejamento compara capacidade descoberta e requests estimados dos componentes. Esses números ajudam a dimensionar a plataforma antes da execução e a identificar excedentes.

Uso observado pertence à telemetria disponível no cluster. No Navigator, capacidade, requests e métricas de uso são conceitos distintos; ausência de coleta não deve ser interpretada como uso zero.

Cada componente possui um perfil e pré-requisitos próprios. Vault HA usa Raft e persistência; Keycloak pode usar banco externo, enquanto seu PostgreSQL local permanece uma réplica. Jenkins, Nexus e SonarQube Community têm perfis de aplicação única; GitLab CE e Harbor também possuem limites de escala no perfil oferecido.

Consulte a configuração e a documentação do componente antes de escolher uma arquitetura de produção. Seleção, instalação confirmada e capacidade de recuperação são estados diferentes.

Existem fluxos de ciclo de vida para componentes suportados, incluindo a stack de observabilidade. Dependências e política de volumes participam da decisão; desativar preservando dados e desinstalar com remoção são ações diferentes.

A disponibilidade varia por componente. Uma seleção no catálogo ou em uma configuração salva não confirma que o runtime pode instalar ou remover aquele item em qualquer cluster.

O Access Center reúne endpoints, URLs, metadados e comandos úteis dos serviços instalados. Application access permite trabalhar com Gateways, listeners, domínios, certificados e rotas de aplicações.

Para alcançar um destino, rede, DNS ou hosts, confiança do certificado e autenticação precisam estar configurados. Um registro de acesso não publica automaticamente a aplicação na internet.

Os provedores que você habilita podem receber evidências permitidas da análise; os tokens permanecem criptografados localmente. A análise utiliza campos permitidos e sinais de diagnóstico; logs brutos e mensagens de eventos permanecem no dispositivo durante a coleta.

Review e Troubleshoot apresentam avaliações e sugestões. Comandos corretivos dependem da sua avaliação e não representam reparo automático. O provedor pode cobrar pelo uso.

O download e a contratação ainda estão indisponíveis nesta prévia. Os planos apresentam a proposta de lançamento, com valores em USD e custos externos separados.

Você pode explorar as telas, comparar os limites e avaliar os requisitos agora. O instalador e a contratação dependem da liberação do lançamento.