Este documento foi traduzido usando tecnologia de tradução automática de máquina. Sempre trabalhamos para apresentar traduções precisas, mas não oferecemos nenhuma garantia em relação à integridade, precisão ou confiabilidade do conteúdo traduzido. Em caso de qualquer discrepância, a versão original em inglês prevalecerá e constituirá o texto official.

Opções Avançadas / Configuração

Esta seção contém informações avançadas descrevendo as diferentes maneiras de executar e gerenciar o K3s, bem como os passos necessários para preparar o sistema operacional do host para o uso do K3s.

Gerenciamento de certificados

Certificados da CA (Autoridade Certificadora)

O K3s gera certificados CA (Autoridade Certificadora) autoassinados durante a inicialização do primeiro nó servidor. Esses certificados CA são válidos por 10 anos e não são renovados automaticamente.

Para informações sobre como usar certificados CA personalizados ou renovar os certificados CA autoassinados, consulte a documentação do comando k3s certificate rotate-ca.

Certificados de Cliente e Servidor

Os certificados de cliente e servidor do K3s são válidos por 365 dias a partir da data de emissão. Quaisquer certificados que estejam expirados ou dentro de 90 dias de expiração são renovados automaticamente toda vez que o K3s é iniciado.

Para informações sobre como rotacionar manualmente os certificados de cliente e servidor, consulte a documentação do comando k3s certificate rotate.

Gerenciamento de token

Por padrão, o K3s usa um único token estático para servidores e agentes. Com cuidado, esse token pode ser rotacionado uma vez que o cluster tenha sido criado. Também é possível habilitar um segundo token estático que pode ser usado apenas para associar agentes, ou criar tokens de junção do tipo kubeadm que expiram automaticamente. Para mais informações, consulte a documentação do comando k3s token.

Configurando a Resolução de DNS

Verificações de Viabilidade do Servidor de Nomes

Na inicialização, cada nó verifica os arquivos em /etc/resolv.conf e /run/systemd/resolve/resolv.conf em busca de servidores de nomes de loopback, multicast ou link-local. Se houver entradas desse tipo, o arquivo de configuração não será utilizado, pois tais entradas não funcionariam corretamente dentro de pods que herdam a configuração de resolução de nomes de seu nó. Se nenhum resolv.conf utilizável for encontrado, o K3s imprime uma mensagem de aviso nos logs e gera um stub resolv.conf que utiliza 8.8.8.8 e 2001:4860:4860::8888 como servidores de nomes.

Se você deseja fornecer ao K3s uma configuração de resolvedor alternativa sem modificar os arquivos de configuração do sistema, pode usar a opção --resolv-conf para especificar o caminho para um arquivo adequado. Arquivos de configuração de resolvedor especificados manualmente não estão sujeitos a verificações de viabilidade.

Importações de Configuração Personalizada do CoreDNS

Para personalizar a configuração do CoreDNS, você pode criar um ConfigMap chamado coredns-custom no namespace kube-system. Chaves que correspondem a .override são importadas para o Bloco de Servidor :.53. Blocos de Servidor adicionais podem ser colocados em chaves que correspondem a .server. Conteúdo adicional (arquivos de zona, etc.) também pode estar presente e é montado sob /etc/coredns/custom nos pods do coredns.

Aqui está um exemplo de ConfigMap que encaminha as consultas de example.com para um servidor de nomes em 10.0.0.1 e serve example.net a partir de um arquivo de texto compatível com RFC 1035:

apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns-custom
  namespace: kube-system
data:
  example-com.override: |
    forward example.com 10.0.0.1
  example-net.server: |
    example.net:53 {
      log
      errors
      file /etc/coredns/custom/db.example.net
    }
  db.example.net: |
    $ORIGIN example.net.
    @       3600 IN SOA    sns.dns.icann.org. noc.dns.icann.org. 2017042745 7200 3600 1209600 3600
            3600 IN NS     a.iana-servers.net.
            3600 IN NS     b.iana-servers.net.
    www          IN A      127.0.0.1
                 IN AAAA   ::1

Configurando um proxy HTTP

Se você estiver executando o K3s em um ambiente que só possui conectividade externa através de um proxy HTTP, pode configurar suas configurações de proxy no serviço systemd do K3s. Essas configurações de proxy serão então usadas no K3s e passadas para o containerd e kubelet incorporados.

A configuração do proxy e outras variáveis de ambiente do host NÃO são passadas para os Pods.

O script de instalação do K3s irá automaticamente pegar as variáveis HTTP_PROXY, HTTPS_PROXY e NO_PROXY, bem como CONTAINERD_HTTP_PROXY, CONTAINERD_HTTPS_PROXY e CONTAINERD_NO_PROXY do shell atual, se estiverem presentes, e escrevê-las no arquivo de ambiente do seu serviço systemd, geralmente:

  • /etc/systemd/system/k3s.service.env

  • /etc/systemd/system/k3s-agent.service.env

Claro, você também pode configurar o proxy editando esses arquivos.

O K3s adicionará automaticamente os intervalos de IP internos de Pod e Serviço do cluster e o domínio DNS do cluster à lista de entradas NO_PROXY. Você deve garantir que os intervalos de endereços IP utilizados pelos próprios nós do Kubernetes (ou seja, os IPs públicos e privados dos nós) estejam incluídos na lista NO_PROXY, ou que os nós possam ser alcançados através do proxy.

HTTP_PROXY=http://your-proxy.example.com:8888
HTTPS_PROXY=http://your-proxy.example.com:8888
NO_PROXY=127.0.0.0/8,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16

Se você deseja configurar as configurações de proxy para o containerd sem afetar o K3s e o Kubelet, pode prefixar as variáveis com CONTAINERD_:

CONTAINERD_HTTP_PROXY=http://your-proxy.example.com:8888
CONTAINERD_HTTPS_PROXY=http://your-proxy.example.com:8888
CONTAINERD_NO_PROXY=127.0.0.0/8,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16

Usando o Docker como o tempo de execução do contêiner

K3s inclui e utiliza por padrão containerd, um tempo de execução do contêiner padrão da indústria. A partir do Kubernetes 1.24, o Kubelet não inclui mais o dockershim, o componente que permite que o kubelet se comunique com o dockerd. K3s 1.24 e versões superiores incluem cri-dockerd, que permite fazer upgrade sem interrupções a partir de versões anteriores do K3s enquanto continua a usar o tempo de execução do contêiner Docker.

Para usar o Docker em vez do containerd:

  1. Instale o Docker no nó do K3s. Um dos scripts de instalação do Docker da Rancher pode ser usado para instalar o Docker:

    curl https://releases.rancher.com/install-docker/20.10.sh | sh

  2. Instale o K3s usando a opção --docker:

    curl -sfL https://get.k3s.io | INSTALL_K3S_ARTIFACT_URL=<PRIME-ARTIFACTS-URL>/k3s sh -s - --docker

  3. Confirme que o cluster está disponível:

    $ sudo k3s kubectl get pods --all-namespaces
NAMESPACE     NAME                                     READY   STATUS      RESTARTS   AGE
kube-system   local-path-provisioner-6d59f47c7-lncxn   1/1     Running     0          51s
kube-system   metrics-server-7566d596c8-9tnck          1/1     Running     0          51s
kube-system   helm-install-traefik-mbkn9               0/1     Completed   1          51s
kube-system   coredns-8655855d6-rtbnb                  1/1     Running     0          51s
kube-system   svclb-traefik-jbmvl                      2/2     Running     0          43s
kube-system   traefik-758cd5fc85-2wz97                 1/1     Running     0          43s

  4. Confirme que os contêineres Docker estão em execução:

    $ sudo docker ps
CONTAINER ID        IMAGE                     COMMAND                  CREATED              STATUS              PORTS               NAMES
3e4d34729602        897ce3c5fc8f              "entry"                  About a minute ago   Up About a minute                       k8s_lb-port-443_svclb-traefik-jbmvl_kube-system_d46f10c6-073f-4c7e-8d7a-8e7ac18f9cb0_0
bffdc9d7a65f        rancher/klipper-lb        "entry"                  About a minute ago   Up About a minute                       k8s_lb-port-80_svclb-traefik-jbmvl_kube-system_d46f10c6-073f-4c7e-8d7a-8e7ac18f9cb0_0
436b85c5e38d        rancher/library-traefik   "/traefik --configfi…"   About a minute ago   Up About a minute                       k8s_traefik_traefik-758cd5fc85-2wz97_kube-system_07abe831-ffd6-4206-bfa1-7c9ca4fb39e7_0
de8fded06188        rancher/pause:3.1         "/pause"                 About a minute ago   Up About a minute                       k8s_POD_svclb-traefik-jbmvl_kube-system_d46f10c6-073f-4c7e-8d7a-8e7ac18f9cb0_0
7c6a30aeeb2f        rancher/pause:3.1         "/pause"                 About a minute ago   Up About a minute                       k8s_POD_traefik-758cd5fc85-2wz97_kube-system_07abe831-ffd6-4206-bfa1-7c9ca4fb39e7_0
ae6c58cab4a7        9d12f9848b99              "local-path-provisio…"   About a minute ago   Up About a minute                       k8s_local-path-provisioner_local-path-provisioner-6d59f47c7-lncxn_kube-system_2dbd22bf-6ad9-4bea-a73d-620c90a6c1c1_0
be1450e1a11e        9dd718864ce6              "/metrics-server"        About a minute ago   Up About a minute                       k8s_metrics-server_metrics-server-7566d596c8-9tnck_kube-system_031e74b5-e9ef-47ef-a88d-fbf3f726cbc6_0
4454d14e4d3f        c4d3d16fe508              "/coredns -conf /etc…"   About a minute ago   Up About a minute                       k8s_coredns_coredns-8655855d6-rtbnb_kube-system_d05725df-4fb1-410a-8e82-2b1c8278a6a1_0
c3675b87f96c        rancher/pause:3.1         "/pause"                 About a minute ago   Up About a minute                       k8s_POD_coredns-8655855d6-rtbnb_kube-system_d05725df-4fb1-410a-8e82-2b1c8278a6a1_0
4b1fddbe6ca6        rancher/pause:3.1         "/pause"                 About a minute ago   Up About a minute                       k8s_POD_local-path-provisioner-6d59f47c7-lncxn_kube-system_2dbd22bf-6ad9-4bea-a73d-620c90a6c1c1_0
64d3517d4a95        rancher/pause:3.1         "/pause"

Usando etcdctl

etcdctl fornece uma CLI para interagir com servidores etcd. K3s não inclui o etcdctl.

Se você deseja usar o etcdctl para interagir com o etcd embutido do K3s, instale o etcdctl usando a documentação oficial.

ETCD_VERSION="v3.5.5"
ETCD_URL="https://github.com/etcd-io/etcd/releases/download/${ETCD_VERSION}/etcd-${ETCD_VERSION}-linux-amd64.tar.gz"
curl -sL ${ETCD_URL} | sudo tar -zxv --strip-components=1 -C /usr/local/bin

Você pode então usar o etcdctl configurando-o para usar os certificados e chaves gerenciados pelo K3s para autenticação:

sudo etcdctl version \
  --cacert=/var/lib/rancher/k3s/server/tls/etcd/server-ca.crt \
  --cert=/var/lib/rancher/k3s/server/tls/etcd/client.crt \
  --key=/var/lib/rancher/k3s/server/tls/etcd/client.key

Configurando o containerd

Versão Gate

K3s inclui o containerd 2.0 a partir das versões de fevereiro de 2025: v1.31.6+k3s1 e v1.32.2+k3s1. Esteja ciente de que o containerd 2.0 prefere a versão de configuração 3, enquanto o containerd 1.7 prefere a versão de configuração 2.

K3s gerará um arquivo de configuração para o containerd em /var/lib/rancher/k3s/agent/etc/containerd/config.toml, usando valores específicos para a configuração atual do cluster e do nó.

Para personalização avançada, você pode criar um modelo de configuração do containerd no mesmo diretório:

  • Para o containerd 2.0, coloque um modelo de configuração da versão 3 em config-v3.toml.tmpl.

    Consulte a documentação do containerd 2.0 para mais informações.

  • Para o containerd 1.7 e versões anteriores, coloque um modelo de configuração da versão 2 em config.toml.tmpl.

    Consulte a documentação do containerd 1.7 para mais informações.

O containerd 2.0 é compatível com versões anteriores de configuração, e o k3s continuará a renderizar a configuração da versão 2 legada a partir de config.toml.tmpl se config-v3.toml.tmpl não for encontrado.

O arquivo de modelo é renderizado na configuração do containerd usando a biblioteca text/template. Consulte ContainerdConfigTemplateV3 e ContainerdConfigTemplate em templates.go para o conteúdo do modelo padrão. O modelo é executado com uma estrutura ContainerdConfig como seu valor dot (argumento de dados).

Modelo base

Você pode estender o modelo base do K3s em vez de copiar e colar o modelo completo do código-fonte do K3s. Isso é útil se você precisar apenas construir sobre a configuração existente, adicionando algumas linhas extras antes ou depois dos padrões.

/var/lib/rancher/k3s/agent/etc/containerd/config-v3.toml.tmpl
{{ template "base" . }}

[plugins.'io.containerd.cri.v1.runtime'.containerd.runtimes.'custom']
  runtime_type = "io.containerd.runc.v2"
[plugins.'io.containerd.cri.v1.runtime'.containerd.runtimes.'custom'.options]
  BinaryName = "/usr/bin/custom-container-runtime"
  SystemdCgroup = true

Para melhores resultados, NÃO simplesmente copie um config.toml pré-renderizado para o modelo e faça suas alterações desejadas. Use o modelo base ou forneça um modelo completo baseado nos padrões do k3s vinculados acima.

Suporte a tempo de execução do contêiner alternativo

O K3s detectará automaticamente runtimes de contêiner alternativos se eles estiverem presentes quando o K3s iniciar. Os tempos de execução do contêiner suportados são:

crun, lunatic, nvidia, nvidia-cdi, nvidia-experimental, slight, spin, wasmedge, wasmer, wasmtime, wws

O K3s usa a variável de ambiente PATH do serviço para procurar executáveis do tempo de execução do contêiner. Se um tempo de execução do contêiner instalado não for detectado pelo K3s, certifique-se de que ele esteja presente em um caminho do sistema, que geralmente inclui: /usr/local/sbin /usr/local/bin /usr/sbin /usr/bin /sbin /bin

Tempo de Execução do Contêiner NVIDIA

As GPUs NVIDIA requerem a instalação do Tempo de Execução do Contêiner NVIDIA para agendar e executar cargas de trabalho aceleradas em Pods. Para usar GPUs NVIDIA com K3s, execute os seguintes passos:

  1. Instale o repositório de pacotes nvidia-container no nó seguindo as instruções em: https://nvidia.github.io/libnvidia-container/

  2. Instale os pacotes do Tempo de Execução do Contêiner NVIDIA. Por exemplo: apt install -y nvidia-container-runtime cuda-drivers-fabricmanager-515 nvidia-headless-515-server

  3. Instale K3s, ou reinicie-o se já estiver instalado.

  4. Confirme que o Tempo de Execução do Contêiner NVIDIA foi encontrado pelo k3s: grep nvidia /var/lib/rancher/k3s/agent/etc/containerd/config.toml

Se esses passos forem seguidos corretamente, o K3s adicionará automaticamente o runtime NVIDIA à configuração do containerd, dependendo dos executáveis de runtime encontrados. K3s inclui definições de RuntimeClass do Kubernetes para todos os runtime alternativos suportados. Você pode selecionar um desses para substituir runc como o runtime padrão em um nó definindo o valor --default-runtime via CLI do k3s ou arquivo de configuração.

Se você não alterou o runtime padrão em seus nós GPU, deve solicitar explicitamente o runtime NVIDIA definindo runtimeClassName: nvidia na especificação do Pod:

apiVersion: v1
kind: Pod
metadata:
  name: nbody-gpu-benchmark
  namespace: default
spec:
  restartPolicy: OnFailure
  runtimeClassName: nvidia
  containers:
  - name: cuda-container
    image: nvcr.io/nvidia/k8s/cuda-sample:nbody
    args: ["nbody", "-gpu", "-benchmark"]
    resources:
      limits:
        nvidia.com/gpu: 1
    env:
    - name: NVIDIA_VISIBLE_DEVICES
      value: all
    - name: NVIDIA_DRIVER_CAPABILITIES
      value: all

Observe que o Runtime de Contêiner NVIDIA também é frequentemente usado com Plugin de Dispositivo NVIDIA, com modificações para garantir que as especificações do pod incluam runtimeClassName: nvidia, conforme mencionado acima.

Executando Servidores Sem Agente (Experimental)

Esse recurso é experimental.

Quando iniciado com a flag --disable-agent, os servidores não executam o kubelet, o runtime, ou o CNI. Eles não registram um recurso de Nó no cluster e não aparecerão na saída de kubectl get nodes. Como não hospedam um kubelet, não podem executar pods ou ser gerenciados por operadores que dependem da enumeração de nós do cluster, incluindo o controlador etcd embutido e o Upgrade Controller.

Executar servidores sem agente pode ser vantajoso se você quiser ocultar seus nós de controle da descoberta por agentes e cargas de trabalho, à custa de um aumento na sobrecarga administrativa causada pela falta de suporte do operador do cluster.

Por padrão, o apiserver em servidores sem agente não poderá fazer conexões de saída para webhooks de admissão ou apiservices agregados em execução dentro do cluster. Para remediar isso, defina a flag do servidor --egress-selector-mode como pod ou cluster. Se você estiver alterando essa flag em um cluster existente, precisará reiniciar todos os nós do cluster para que a opção tenha efeito.

Executando Servidores Sem Raiz (Experimental)

Esse recurso é experimental.

O modo sem raiz permite executar servidores K3s como um usuário não privilegiado, para proteger a raiz real no host de possíveis ataques de quebra de contêiner.

Consulte https://rootlesscontaine.rs/ para saber mais sobre Kubernetes Sem Raiz.

Problemas Conhecidos com o modo sem raiz

  • Portas

    Ao executar sem raiz, um novo namespace de rede é criado. Isso significa que a instância do K3s está sendo executada com a rede bastante desconectada do host. A única maneira de acessar os Serviços executados no K3s a partir do host é configurar encaminhamentos de porta para o namespace de rede do K3s. O K3s sem raiz inclui um controlador que automaticamente vinculará a porta 6443 e as portas de serviço abaixo de 1024 ao host com um deslocamento de 10000.

    Por exemplo, um Serviço na porta 80 se tornará 10080 no host, mas 8080 se tornará 8080 sem nenhum deslocamento. Atualmente, apenas Serviços LoadBalancer são automaticamente vinculados.

  • Cgroups

    Cgroup v1 e Hybrid v1/v2 não são suportados; apenas Cgroup v2 puro é suportado. Se o K3s falhar ao iniciar devido a cgroups ausentes ao executar sem raiz, é provável que seu nó esteja no modo híbrido, e os cgroups "ausentes" ainda estão vinculados a um controlador v1.

  • Cluster multi-nó/multi-processo

    Clusters sem raiz de múltiplos nós, ou múltiplos processos k3s sem raiz no mesmo nó, não são atualmente suportados. Consulte #6488 para mais detalhes.

Iniciando Servidores Sem Raiz

  • Ative a delegação de cgroup v2, consulte https://rootlesscontaine.rs/getting-started/common/cgroup2/. Esta etapa é necessária; o kubelet sem raiz falhará ao iniciar sem os cgroups adequadamente delegados.

  • Baixe k3s-rootless.service de https://github.com/k3s-io/k3s/blob/<VERSION>/k3s-rootless.service. Certifique-se de usar a mesma versão de k3s-rootless.service e k3s.

  • Instale k3s-rootless.service em ~/.config/systemd/user/k3s-rootless.service. Instalar este arquivo como um serviço em todo o sistema (/etc/systemd/…​) não é suportado. Dependendo do caminho do binário k3s, pode ser necessário modificar a linha ExecStart=/usr/local/bin/k3s …​ do arquivo.

  • Execute systemctl --user daemon-reload

  • Execute systemctl --user enable --now k3s-rootless

  • Execute KUBECONFIG=~/.kube/k3s.yaml kubectl get pods -A e certifique-se de que os pods estão em execução.

Não tente executar k3s server --rootless em um terminal, pois sessões de terminal não permitem delegação de cgroup v2. Se você realmente precisar tentar em um terminal, use systemd-run --user -p Delegate=yes --tty k3s server --rootless para envolvê-lo em um escopo systemd.

Configuração Avançada Sem Raiz

O K3s sem raiz usa rootlesskit e slirp4netns para se comunicar entre os namespaces de rede do host e do usuário. Algumas das configurações usadas pelo rootlesskit e slirp4nets podem ser definidas por variáveis de ambiente. A melhor maneira de definir isso é adicioná-las ao campo Environment da unidade systemd k3s-rootless.

Variável Default Descrição

K3S_ROOTLESS_MTU

1500

Define o MTU para as interfaces virtuais slirp4netns.

K3S_ROOTLESS_CIDR

10.41.0.0/16

Define o CIDR usado pelas interfaces virtuais slirp4netns.

K3S_ROOTLESS_ENABLE_IPV6

autodetectado

Habilita o suporte IPv6 do slirp4netns. Se não especificado, é habilitado automaticamente se o K3s estiver configurado para operação em pilha dupla.

K3S_ROOTLESS_PORT_DRIVER

builtin

Seleciona o driver de porta sem raiz; seja builtin ou slirp4netns. Embutido é mais rápido, mas mascara o endereço de origem original dos pacotes de entrada.

K3S_ROOTLESS_DISABLE_HOST_LOOPBACK

true

Controla se o acesso ao endereço de loopback do host via a interface do gateway está habilitado ou não. Recomenda-se que isso não seja alterado, por razões de segurança.

Solução de Problemas Sem Raiz

  • Execute systemctl --user status k3s-rootless para verificar o status do daemon

  • Execute journalctl --user -f -u k3s-rootless para ver o log do daemon

  • Consulte também https://rootlesscontaine.rs/

Rótulos e taints de nó

Os agentes K3s podem ser configurados com as opções --node-label e --node-taint, que adicionam um rótulo e um taint ao kubelet. As duas opções apenas adicionam rótulos e/ou taints no momento do registro, portanto, só podem ser definidas quando o nó é adicionado ao cluster pela primeira vez.

Todas as versões atuais do Kubernetes restringem os nós de se registrarem com a maioria dos rótulos com os prefixos kubernetes.io e k8s.io, incluindo especificamente o rótulo kubernetes.io/role. Se você tentar iniciar um nó com um rótulo não permitido, o K3s falhará ao iniciar. Como afirmado pelos autores do Kubernetes:

Os nós não têm permissão para afirmar seus próprios rótulos de função. Os papéis dos nós são tipicamente usados para identificar tipos de nós privilegiados ou de plano de controle, e permitir que os nós se rotulem nesse grupo permite que um nó comprometido atraia facilmente cargas de trabalho (como daemonsets de plano de controle) que conferem acesso a credenciais de maior privilégio.

Consulte SIG-Auth KEP 279 para mais informações.

Se você quiser alterar rótulos e taints de nós após o registro do nó, ou adicionar rótulos reservados, deve usar kubectl. Consulte a documentação oficial do Kubernetes para detalhes sobre como adicionar taints e rótulos de nó.

Iniciando o serviço com o script de instalação

O script de instalação detectará automaticamente se seu sistema operacional está usando systemd ou openrc e habilitará e iniciará o serviço como parte do processo de instalação.

  • Ao executar com openrc, os logs serão criados em /var/log/k3s.log.

  • Ao executar com systemd, os logs serão criados em /var/log/syslog e visualizados usando journalctl -u k3s (ou journalctl -u k3s-agent em agentes).

Um exemplo de desabilitar a inicialização automática e a habilitação do serviço com o script de instalação:

curl -sfL https://get.k3s.io | INSTALL_K3S_ARTIFACT_URL=<PRIME-ARTIFACTS-URL>/k3s INSTALL_K3S_SKIP_START=true INSTALL_K3S_SKIP_ENABLE=true sh -

Executando K3s no Docker

Existem várias maneiras de executar K3s no Docker:

  • K3d

  • Docker

k3d é uma ferramenta projetada para executar facilmente clusters K3s de múltiplos nós no Docker.

k3d torna muito fácil criar clusters k3s de um único nó e de múltiplos nós no Docker, por exemplo, para desenvolvimento local no Kubernetes.

Consulte a documentação de Instalação para mais informações sobre como instalar e usar o k3d.

Para usar o Docker, rancher/k3s imagens também estão disponíveis para executar o servidor e o agente K3s. Usando o comando docker run:

sudo docker run \
  --privileged \
  --name k3s-server-1 \
  --hostname k3s-server-1 \
  -p 6443:6443 \
  -d rancher/k3s:v1.24.10-k3s1 \
  server

Você deve especificar uma versão válida do K3s como a tag; a tag latest não é mantida.
Imagens do Docker não permitem um sinal + nas tags, use um - na tag em vez disso.

Uma vez que o K3s esteja em funcionamento, você pode copiar o kubeconfig do administrador para fora do contêiner Docker para uso:

sudo docker cp k3s-server-1:/etc/rancher/k3s/k3s.yaml ~/.kube/config

Suporte ao SELinux

Se você estiver instalando o K3s em um sistema onde o SELinux está habilitado por padrão (como o CentOS), você deve garantir que as políticas SELinux adequadas tenham sido instaladas.

  • Instalação automática

  • Instalação manual

O script de instalação instalará automaticamente o RPM do SELinux do repositório RPM do Rancher se estiver em um sistema compatível, caso não esteja realizando uma instalação air-gapped. A instalação automática pode ser pulada definindo INSTALL_K3S_SKIP_SELINUX_RPM=true.

As políticas necessárias podem ser instaladas com os seguintes comandos:

yum install -y container-selinux selinux-policy-base
yum install -y https://rpm.rancher.io/k3s/latest/common/centos/9/noarch/k3s-selinux-1.6-1.el9.noarch.rpm

Para forçar o script de instalação a registrar um aviso em vez de falhar, você pode definir a seguinte variável de ambiente: INSTALL_K3S_SELINUX_WARN=true.

Habilitando a aplicação do SELinux

Para aproveitar o SELinux, especifique a flag --selinux ao iniciar servidores e agentes K3s ou ao definir a variável de ambiente K3S_SELINUX=true.

Esta opção também pode ser especificada no arquivo de configuração do K3s.

selinux: true

Usar um --data-dir personalizado sob o SELinux não é suportado. Para personalizá-lo, você provavelmente precisaria escrever sua própria política personalizada. Para orientação, você pode consultar o repositório containers/container-selinux, que contém os arquivos de política do SELinux para tempos de execução do contêiner, e o repositório k3s-io/k3s-selinux, que contém a política do SELinux para o K3s.

Habilitando a extração preguiçosa de eStargz (Experimental)

O que é extração preguiçosa e eStargz?

Puxar imagens é conhecido como um dos passos que consomem mais tempo no ciclo de vida do contêiner. De acordo com Harter, et al.,

puxar pacotes representa 76% do tempo de inicialização do contêiner, mas apenas 6,4% desses dados são lidos.

Para resolver esse problema, o k3s suporta experimentalmente extração preguiçosa do conteúdo da imagem. Isso permite que o k3s inicie um contêiner antes que a imagem inteira tenha sido puxada. Em vez disso, os pedaços necessários de conteúdo (por exemplo, arquivos individuais) são buscados sob demanda. Especialmente para imagens grandes, essa técnica pode encurtar a latência de inicialização do contêiner.

Para habilitar a extração preguiçosa, a imagem alvo precisa ser formatada como eStargz. Este é um formato de imagem alternativo ao OCI, mas 100% compatível com OCI para extração preguiçosa. Devido à compatibilidade, o eStargz pode ser enviado para registros de contêiner padrão (por exemplo, ghcr.io) e ainda é executável mesmo em runtimes que não suportam eStargz.

O eStargz é desenvolvido com base no formato stargz proposto pelo projeto Google CRFS, mas vem com recursos práticos, incluindo verificação de conteúdo e otimização de desempenho. Para mais detalhes sobre extração preguiçosa e eStargz, consulte o repositório do projeto Stargz Snapshotter.

Configure o k3s para extração preguiçosa de eStargz

Como mostrado a seguir, a opção --snapshotter=stargz é necessária para o servidor e agente k3s.

k3s server --snapshotter=stargz

Com esta configuração, você pode realizar a extração preguiçosa para imagens no formato eStargz. O seguinte manifesto de Pod de exemplo usa uma imagem no formato eStargz node:13.13.0 (ghcr.io/stargz-containers/node:13.13.0-esgz). Quando o snapshotter stargz está habilitado, o K3s realiza a extração preguiçosa para esta imagem.

apiVersion: v1
kind: Pod
metadata:
  name: nodejs
spec:
  containers:
  - name: nodejs-estargz
    image: ghcr.io/stargz-containers/node:13.13.0-esgz
    command: ["node"]
    args:
    - -e
    - var http = require('http');
      http.createServer(function(req, res) {
        res.writeHead(200);
        res.end('Hello World!\n');
      }).listen(80);
    ports:
    - containerPort: 80

Fontes de Log Adicionais

O logging do Rancher para o K3s pode ser instalado sem usar o Rancher. As seguintes instruções devem ser executadas para isso:

helm repo add rancher-charts https://charts.rancher.io
helm repo update
helm install --create-namespace -n cattle-logging-system rancher-logging-crd rancher-charts/rancher-logging-crd
helm install --create-namespace -n cattle-logging-system rancher-logging --set additionalLoggingSources.k3s.enabled=true rancher-charts/rancher-logging

Registro Adicional de Políticas de Rede

Pacotes descartados por políticas de rede podem ser registrados em log. O pacote é enviado para a ação NFLOG do iptables, que mostra os detalhes do pacote, incluindo a política de rede que o bloqueou.

Se houver muito tráfego, o número de mensagens de log pode ser muito alto. Para controlar a taxa de registro por política, defina os parâmetros limit e limit-burst do iptables adicionando as seguintes anotações à política de rede em questão:

  • kube-router.io/netpol-nflog-limit=<LIMIT-VALUE>

  • kube-router.io/netpol-nflog-limit-burst=<LIMIT-BURST-VALUE>

Os valores padrão são limit=10/minute e limit-burst=10. Verifique o manual do iptables para mais informações sobre o formato e os possíveis valores para esses campos.

Para converter pacotes NFLOG em entradas de log, instale o ulogd2 e configure [log1] para ler em group=100. Em seguida, reinicie o serviço ulogd2 para que a nova configuração seja aplicada. Quando um pacote é bloqueado por regras de política de rede, uma mensagem de registro aparecerá em /var/log/ulog/syslogemu.log.

Pacotes enviados para o socket netlink NFLOG também podem ser lidos usando ferramentas de linha de comando como tcpdump ou tshark:

tcpdump -ni nflog:100

Embora mais facilmente disponível, o tcpdump não mostrará o nome da política de rede que bloqueou o pacote. Use o comando tshark do wireshark em vez disso para exibir o cabeçalho completo do pacote NFLOG, incluindo o campo nflog.prefix que contém o nome da política.

O registro de Política de Rede de pacotes descartados não suporta políticas com um podSelector vazio. Se você depender do registro de pacotes descartados para fins de diagnóstico ou auditoria, certifique-se de que suas políticas incluam um seletor de pod que corresponda aos pods afetados.