Início / server / Perguntas / 1163134
Accepted
Xu Shijie
Asked: 2024-07-27 13:26:09 +0800 CST

local de instalação do kubelet, kubeschedule e etcd após a remoção da purga

  • 772

Para reinstalar meu cluster local usando kubeadm, executei os seguintes comandos:

sudo apt-get purge -y kubeadm kubectl kubelet kubernetes-cni  kubelet kube-apiserver kube-scheduler kube-controller-manager kube-proxy
sudo apt-get autoremove -y

e reinicie minha máquina.

O problema é que ainda encontro vários processos kube usando ps:

(base) ➜  ~ ps -ef | grep kube 
root        9198    8816  3 12:46 ?        00:01:11 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --config=/var/lib/kubelet/config.yaml --container-runtime-endpoint=unix:///run/containerd/containerd.sock --node-ip=172.23.0.2 --node-labels= --pod-infra-container-image=registry.k8s.io/pause:3.9 --provider-id=kind://docker/kind/kind-control-plane --fail-swap-on=false --cgroup-root=/kubelet
root        9480    9312  2 12:46 ?        00:00:52 kube-controller-manager --allocate-node-cidrs=true --authentication-kubeconfig=/etc/kubernetes/controller-manager.conf --authorization-kubeconfig=/etc/kubernetes/controller-manager.conf --bind-address=127.0.0.1 --client-ca-file=/etc/kubernetes/pki/ca.crt --cluster-cidr=10.244.0.0/16 --cluster-name=kind --cluster-signing-cert-file=/etc/kubernetes/pki/ca.crt --cluster-signing-key-file=/etc/kubernetes/pki/ca.key --controllers=*,bootstrapsigner,tokencleaner --enable-hostpath-provisioner=true --kubeconfig=/etc/kubernetes/controller-manager.conf --leader-elect=true --requestheader-client-ca-file=/etc/kubernetes/pki/front-proxy-ca.crt --root-ca-file=/etc/kubernetes/pki/ca.crt --service-account-private-key-file=/etc/kubernetes/pki/sa.key --service-cluster-ip-range=10.96.0.0/16 --use-service-account-credentials=true
root        9513    9313  0 12:46 ?        00:00:11 kube-scheduler --authentication-kubeconfig=/etc/kubernetes/scheduler.conf --authorization-kubeconfig=/etc/kubernetes/scheduler.conf --bind-address=127.0.0.1 --kubeconfig=/etc/kubernetes/scheduler.conf --leader-elect=true
root        9550    9352  6 12:46 ?        00:02:13 kube-apiserver --advertise-address=172.23.0.2 --allow-privileged=true --authorization-mode=Node,RBAC --client-ca-file=/etc/kubernetes/pki/ca.crt --enable-admission-plugins=NodeRestriction --enable-bootstrap-token-auth=true --etcd-cafile=/etc/kubernetes/pki/etcd/ca.crt --etcd-certfile=/etc/kubernetes/pki/apiserver-etcd-client.crt --etcd-keyfile=/etc/kubernetes/pki/apiserver-etcd-client.key --etcd-servers=https://127.0.0.1:2379 --kubelet-client-certificate=/etc/kubernetes/pki/apiserver-kubelet-client.crt --kubelet-client-key=/etc/kubernetes/pki/apiserver-kubelet-client.key --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname --proxy-client-cert-file=/etc/kubernetes/pki/front-proxy-client.crt --proxy-client-key-file=/etc/kubernetes/pki/front-proxy-client.key --requestheader-allowed-names=front-proxy-client --requestheader-client-ca-file=/etc/kubernetes/pki/front-proxy-ca.crt --requestheader-extra-headers-prefix=X-Remote-Extra- --requestheader-group-headers=X-Remote-Group --requestheader-username-headers=X-Remote-User --runtime-config= --secure-port=6443 --service-account-issuer=https://kubernetes.default.svc.cluster.local --service-account-key-file=/etc/kubernetes/pki/sa.pub --service-account-signing-key-file=/etc/kubernetes/pki/sa.key --service-cluster-ip-range=10.96.0.0/16 --tls-cert-file=/etc/kubernetes/pki/apiserver.crt --tls-private-key-file=/etc/kubernetes/pki/apiserver.key
root        9557    9344  3 12:46 ?        00:01:06 etcd --advertise-client-urls=https://172.23.0.2:2379 --cert-file=/etc/kubernetes/pki/etcd/server.crt --client-cert-auth=true --data-dir=/var/lib/etcd --experimental-initial-corrupt-check=true --experimental-watch-progress-notify-interval=5s --initial-advertise-peer-urls=https://172.23.0.2:2380 --initial-cluster=kind-control-plane=https://172.23.0.2:2380 --key-file=/etc/kubernetes/pki/etcd/server.key --listen-client-urls=https://127.0.0.1:2379,https://172.23.0.2:2379 --listen-metrics-urls=http://127.0.0.1:2381 --listen-peer-urls=https://172.23.0.2:2380 --name=kind-control-plane --peer-cert-file=/etc/kubernetes/pki/etcd/peer.crt --peer-client-cert-auth=true --peer-key-file=/etc/kubernetes/pki/etcd/peer.key --peer-trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt --snapshot-count=10000 --trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt
root       10082   10017  0 12:46 ?        00:00:00 /usr/local/bin/kube-proxy --config=/var/lib/kube-proxy/config.conf --hostname-override=kind-control-plane

Mas não consegui encontrar esses arquivos (por exemplo, kube-proxy, kubelet, kube-apiserver e kube-scheduler) nos diretórios, como root:

(base) ➜  ~ ll /usr/bin/kubelet                
ls: cannot access '/usr/bin/kubelet': No such file or directory
(base) ➜  ~ kubectl 
zsh: command not found: kubectl
(base) ➜  ~ 
(base) ➜  ~ sudo kube-apiserver --help            
sudo: kube-apiserver: command not found
(base) ➜  ~ cd /usr/bin          
(base) ➜  bin ls kubelet 
ls: cannot access 'kubelet': No such file or directory
(base) ➜  bin ll kube-controller-manager                
ls: cannot access 'kube-controller-manager': No such file or directory
(base) ➜  bin ll kube-apiserver                       
ls: cannot access 'kube-apiserver': No such file or directory

Alguém poderia ajudar a explicar como esses processos são lançados? Obrigado.

kubernetes

1 respostas

  1. Best Answer

    O desafio que você tem é que, mesmo que você tenha usado kubeadm purge e apt-get autoremove para excluir os pacotes kubernetes, os serviços systemd que lidam com esses processos ainda estão em execução e tentando iniciá-los.

    Isso implica que usando o apt-get-purge, você conseguiu remover completamente os binários do kubernetes como kubelet, kube-apiserver entre outros. No entanto, é provável que os serviços do sistema para gerenciar esses binários ainda estejam habilitados e se esforcem para executá-los, embora seus arquivos estejam faltando.

    /etc /systemd/system/ é um local típico onde os serviços systemd para componentes kubernetes podem ser encontrados.

    Para lidar com esta situação, use sudo systemctl stop kubelet kube-apiserver kube- controller- manager kube- scheduler kube- proxy etcdpara encerrar todos os processos de serviço em execução.

    Pense também em desativá-los. Para desabilitar qualquer um desses serviços basta digitar sudo systemctl disable kubelet kube-apiserbver kube- controller- manager kube-scheduler jube -proxy etcdpara não ativá-los novamente após inicializar o PC.

    Além disso, verifique se há algum arquivo ou pasta de configuração restante referente ao Kubernetes após interrompê-lo. Eles serão colocados em diretórios como /etc/kubernetes ou /var/lib/kubernetes.

    Se você seguir essas instruções bem o suficiente, desabilitando adequadamente todos os principais serviços restantes do Kubernetes ou limpando tudo e preparando-se novamente para o processo de reinstalação via Kubeadm.

    • 0

relate perguntas