web-dev-qa-db-fra.com

Comment passer des indicateurs lors du démarrage d'un service systemd?

Notez qu'une question similaire a été posée:
Comment passer des drapeaux au démarrage du 'service'?
Mais j’ai lu il ya quelque temps que Linux passait d’init.d à systemd et, depuis que le Q & A a 6 ans, je pensais que cela pourrait faire référence à init.d

Ma question est:
Comment passez-vous les indicateurs/arguments lors du démarrage d'un service systemd? Disons que je ne redémarre pas Kubelet depuis le système, cela signifie que le service Kubelet est en cours d'exécution. Comment puis-je voir et modifier les indicateurs/arguments transmis à ce service? (Comme --anonymous-auth = false)

Aussi voici un peu de contexte:
Je suis sur le point de planifier mon examen de certification CNCF Kubernetes. Cet examen est basé sur les performances et couvre des sujets essentiels qui sont généralement abstraits d'un administrateur de cluster.

Ce que j’ai appris, c’est qu’il existe 7 binaires de base qui composent Kubernetes: [docker, etcd, kube-apiserver, kube-controller-manager, kube-scheduler, kube-proxy et kubelet]

Certains de ces binaires du plan de contrôle Kubernetes sont "auto-hébergés"/exécutés en tant que pods sur Kubernetes, et vous transmettez des arguments/indicateurs tels que --service-cluster-ip-range = 10.0.0.0/16

L'URL suivante présente un exemple de fichiers binaires principaux exécutés en tant que conteneurs Docker sur Kubernetes, ainsi que les indicateurs transmis en tant qu'arguments dans la spécification YAML. https://kubernetes.io/docs/setup/scratch/#scheduler-pod-template

D'autres binaires Core Kubernetes, tels que Kubelet et Docker, ne conviennent pas à l'auto-hébergement. Ils sont exécutés en tant que démons système Linux. Ils s'exécutent avec systemd et sont gérés avec systemctl et journalctl. Quoi qu'il en soit, j'ai déjà dû me connecter à un nœud et redémarrer Systemctl docker.service et Systemctl redémarrer kubelet.service auparavant, mais je ne sais pas comment voir ni modifier les indicateurs/arguments qui leur sont transmis.

jujusystemdservicesdockerkubernetes
1
neokyle

De ici cela peut être fait comme suit:

  1. Créez un fichier argumants dites /etc/.argconf

    ARG1=-o
ARG2=--verbose

  2. Et votre fichier .service:

    EnvironmentFile=/etc/.progconf
ExecStart = /usr/bin/prog $ARG1 $ARG2

Une autre méthode de ce même message est comme ci-dessous:

[Unit]
Description=Test passing multiple arguments

[Service]
Environment="SCRIPT_ARGS=%I"
ExecStart=/tmp/test.py $SCRIPT_ARGS

Et le nom du fichier doit être [email protected] prenez note du @ car il est nécessaire pour passer des arguments de cette manière à un service. Vous exécutez alors ce service comme suit:

Sudo systemctl start myseervic@"arg1 arg2 arg3".service
1
George Udosen

Tout comme chaque implémentation/saveur/distribution de Linux est un peu différente.
J'ai appris que chaque implémentation de Kuberntes est un peu différente.
Et qu’il existe différentes façons de mettre en œuvre systemd.

Avec toute cette variabilité, je crois que la meilleure façon de faire cela semble être:
Utiliser la commande find pour trouver où se trouve * .service

WorkerNodeBash # find/-name "* .service" | grep -i "kube"
WorkerNodeBash # nano /etc/systemd/system/kubelet.service

[Unit]
Description=Kubernetes Kubelet
Documentation=https://github.com/kubernetes/kubernetes
After=containerd.service
Requires=containerd.service

[Service]
ExecStart=/usr/local/bin/kubelet \
  --config=/var/lib/kubelet/kubelet-config.yaml \
  --container-runtime=remote \
  --container-runtime-endpoint=unix:///var/run/containerd/containerd.sock \
  --image-pull-progress-deadline=2m \
  --kubeconfig=/var/lib/kubelet/kubeconfig \
  --network-plugin=cni \
  --register-node=true \
  --pod-manifest-path=/etc/kubernetes/manifests \
  --v=2
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

(Ce qui précède provient de Kubernetes, mais j'ai aussi fait kubeadm et ai regardé dans ce même fichier sans voir d'arguments, mais grâce à l'apprentissage de l'utilisation de la commande find, j'ai pu chercher:
WorkerNodeBash # find/-type f -name "* .yaml" | grep "kube"
Et j’ai trouvé un fichier de configuration mentionnant KUBELET_EXTRA_ARGS = et les ai passés ici.

0
neokyle