leia
1.31.2
CRI-O segue os ciclos de lançamento do Kubernetes em relação às suas versões secundárias ( 1.xy ). Os lançamentos de patches ( 1.xz ) para Kubernetes não estão sincronizados com os do CRI-O, porque são agendados para cada mês, enquanto o CRI-O os fornece apenas se necessário. Se uma versão do Kubernetes chegar ao fim da vida útil, a versão CRI-O correspondente poderá ser considerada da mesma maneira.
Isso significa que o CRI-O também segue a política de distorção da versão de lançamento do Kubernetes n-2 quando se trata de graduação, descontinuação ou remoção de recursos. Isso também se aplica a recursos independentes do Kubernetes. No entanto, backports de recursos para ramificações de lançamento suportadas, que são independentes do Kubernetes ou de outras ferramentas como cri-tools, ainda são possíveis. Isso permite que o CRI-O se separe do ciclo de lançamento do Kubernetes e tenha flexibilidade suficiente quando se trata de implementar novos recursos. Cada recurso a ser portado será uma decisão caso a caso da comunidade, enquanto a matriz geral de compatibilidade não deve ser comprometida.
Para obter mais informações, visite a Política de distorção de versão do Kubernetes.
| CRI-O | Kubernetes | Status de manutenção |
|---|---|---|
ramo main | ramo master | Os recursos do repositório principal do Kubernetes são implementados ativamente |
ramificação release-1.x ( v1.xy ) | ramificação release-1.x ( v1.xz ) | A manutenção é manual, apenas correções de bugs serão suportadas. |
As notas de lançamento do CRI-O são feitas à mão e podem ser recuperadas continuamente em nosso site GitHub.
O objetivo do CRI-O é fornecer um caminho de integração entre tempos de execução em conformidade com OCI e o Kubelet. Especificamente, ele implementa o Kubelet Container Runtime Interface (CRI) usando tempos de execução em conformidade com OCI. O escopo do CRI-O está vinculado ao escopo do CRI.
Em alto nível, esperamos que o escopo do CRI-O seja restrito às seguintes funcionalidades:
CRI-O é uma implementação do Kubernetes Container Runtime Interface (CRI) que permitirá ao Kubernetes lançar e gerenciar diretamente contêineres da Open Container Initiative (OCI).
O plano é usar projetos OCI e as melhores bibliotecas para diferentes aspectos:
Atualmente está em desenvolvimento ativo na comunidade Kubernetes por meio da proposta de design. Perguntas e questões devem ser levantadas no canal Slack do nó de sinalização do Kubernetes.
Um roteiro que descreve a direção do CRI-O pode ser encontrado aqui. O projeto está monitorando todos os esforços contínuos como parte do projeto Feature Roadmap GitHub.
O CI do CRI-O é dividido entre ações do GitHub e OpenShift CI (Prow). Imagens de máquinas virtuais relevantes usadas para os trabalhos prow são criadas periodicamente nos trabalhos:
Os trabalhos são mantidos no repositório openshift/release e definem fluxos de trabalho usados para os trabalhos específicos. As definições de trabalho reais podem ser encontradas no mesmo repositório em ci-operator/jobs/cri-o/cri-o/cri-o-cri-o-main-presubmits.yaml para o branch main , bem como os arquivos correspondentes para os ramos de lançamento. A configuração da imagem base para esses trabalhos está disponível no mesmo repositório em ci-operator/config/cri-o/cri-o.
| Comando | Descrição |
|---|---|
| crio(8) | Daemon de tempo de execução do contêiner OCI Kubernetes |
Exemplos de ferramentas de linha de comando para interagir com CRI-O (ou outros tempos de execução compatíveis com CRI) são Crictl e Podman.
| Arquivo | Descrição |
|---|---|
| crio.conf(5) | Arquivo de configuração CRI-O |
| política.json(5) | Arquivo(s) de política de verificação de assinatura |
| registros.conf(5) | Arquivo de configuração de registros |
| armazenamento.conf(5) | Arquivo de configuração de armazenamento |
O processo de segurança para relatar vulnerabilidades é descrito em SECURITY.md.
Você pode configurar o CRI-O para injetar ganchos OCI ao criar contêineres.
Fornecemos informações úteis para operações e transferência de desenvolvimento no que se refere à infraestrutura que utiliza CRI-O.
Para comunicação assíncrona e discussões longas, use problemas e solicitações pull no repositório GitHub. Este será o melhor lugar para discutir design e implementação.
Para comunicação por chat, temos um canal no slack do Kubernetes onde todos são bem-vindos para participar e conversar sobre desenvolvimento.
Mantemos uma lista selecionada de links relacionados ao CRI-O. Você encontrou algo interessante na web sobre o projeto? Incrível, fique à vontade para abrir um PR e adicioná-lo à lista.
Para instalar CRI-O , você pode seguir nosso guia de instalação. Alternativamente, se você preferir construir CRI-O a partir do código-fonte, consulte nosso guia de configuração.
Antes de começar, você precisará iniciar o CRI-O
Você pode executar uma versão local do Kubernetes com CRI-O usando local-up-cluster.sh :
CGROUP_DRIVER=systemd
CONTAINER_RUNTIME=remote
CONTAINER_RUNTIME_ENDPOINT='unix:///var/run/crio/crio.sock'
./hack/local-up-cluster.sh Para obter mais orientações sobre como executar CRI-O , visite nossa página de tutorial
CRI-O expõe por padrão a API gRPC para atender à Container Runtime Interface (CRI) do Kubernetes. Além disso, existe uma API HTTP adicional para recuperar mais informações de status de tempo de execução sobre CRI-O. Esteja ciente de que esta API não é considerada estável e os casos de uso de produção não devem depender dela.
Em uma instância CRI-O em execução, podemos acessar a API por meio de uma ferramenta de transferência HTTP como curl:
$ sudo curl -v --unix-socket /var/run/crio/crio.sock http://localhost/info | jq
{
"storage_driver": "btrfs",
"storage_root": "/var/lib/containers/storage",
"cgroup_driver": "systemd",
"default_id_mappings": { ... }
}Os seguintes pontos de entrada da API são atualmente suportados:
| Caminho | Tipo de conteúdo | Descrição |
|---|---|---|
/info | application/json | Informações gerais sobre o tempo de execução, como storage_driver e storage_root . |
/containers/:id | application/json | Informações dedicadas do contêiner, como name , pid e image . |
/config | application/toml | A configuração TOML completa (o padrão é /etc/crio/crio.conf ) usada pelo CRI-O. |
/pause/:id | application/json | Pause um contêiner em execução. |
/unpause/:id | application/json | Retome um contêiner pausado. |
/debug/goroutines | text/plain | Imprima as pilhas goroutine. |
/debug/heap | text/plain | Escreva o despejo de heap. |
O subcomando crio status pode ser usado para acessar a API com uma ferramenta de linha de comando dedicada. Ele oferece suporte a todos os endpoints da API por meio dos subcomandos dedicados config , info e containers , por exemplo:
$ sudo crio status info
cgroup driver: systemd
storage driver: btrfs
storage root: /var/lib/containers/storage
default GID mappings (format ::):
0:0:4294967295
default UID mappings (format ::):
0:0:4294967295 Consulte o guia CRI-O Metrics.
Consulte o guia CRI-O Tracing.
Alguns aspectos do Container Runtime merecem alguma explicação adicional. Esses detalhes estão resumidos em um guia dedicado.
Está com algum problema? Existem algumas dicas e truques para depuração localizados em nosso guia de depuração
Uma lista incompleta de adotantes do CRI-O em ambientes de produção pode ser encontrada aqui. Se você é um usuário, ajude-nos a concluí-lo enviando uma solicitação pull!
Uma reunião semanal é realizada para discutir o desenvolvimento do CRI-O. Está aberto a todos. Os detalhes para participar da reunião estão no wiki.
Para obter mais informações sobre como o CRI-O é governado, dê uma olhada no arquivo de governança
