0
votes

Docker Conteneur Auto Healing est Kubettes Convient à une instance?

J'ai un conteneur Docker Qu'est-ce que le pyppeteer est en cours d'exécution. Il a une fuite de mémoire, de sorte qu'il sera arrêté dans 24 heures.

J'ai besoin d'un système de guérison automatique, je pense que Kubettes peut le faire. Pas de béquilibre, une seule instance, un conteneur. Il convient?

++++

Enfin, j'ai sélectionné Docker-Py, géré par l'utilisation de conteneurs.Run, conteneurs.Prune.

Cela fonctionne pour moi.


0 commentaires

4 Réponses :


0
votes

Il existe plusieurs options pour votre cas d'utilisation, l'un d'entre eux est en cours d'exécution Kubettes. Mais vous devriez considérer les frais généraux sur les ressources et le fardeau d'entretien lors de la course à Kubettes pour un seul conteneur.

Je vous suggère d'explorer que SystemD redémarre votre conteneur au cas où il s'écrase ou utilisez simplement Docker lui-même: avec le - redémarrage = Toujours Paramètre Le démon Docker assure que le conteneur est en cours d'exécution. Remarque: même après le redémarrage du système System Docker s'assurera que le conteneur est redémarré dans ce cas. Ainsi, un - redémarrage = échec de l'échec pourrait être une meilleure option.

Voir cette page pour plus d'informations: https://docs.docker.com/config/containers/start-Containers-automatics/#use-a-restart-policy


1 commentaires

J'avais essayé l'option --Restart = toujours, mais cela ne clut pas de mémoire. alors ne pouvait pas auto-guérir. Je veux exécuter un nouveau conteneur.



2
votes

Si votre conteneur n'a aucun état et que vous savez qu'il va être à court de mémoire toutes les 24 heures, je dirais que Cronjob est la meilleure option.

Vous pouvez faire ce que vous voulez sur les K8, mais c'est surchargé. Cluster de K8S entier pour un conteneur, ne sonne pas bien pour moi.

Une autre chose est que si vous avez plus d'applications ou de conteneurs car les K8 peuvent exécuter de nombreux services indépendants d'un autre, de sorte que vous ne gaspillez pas des ressources.


0 commentaires

0
votes

Je n'ai pas travaillé avec la marionnettiste mais après de courtes recherches trouvées Ceci :

Par défaut, Docker exécute un conteneur avec un espace mémoire partagé par A / dev / shm 64 Mo. Ceci est généralement trop petit pour chrome et provoquera un crash chrome lorsqu'il rend de grandes pages. Pour résoudre, exécutez le conteneur avec Docker Run-the-Taille = 1 Go pour augmenter la taille de / dev / shm. Depuis Chrome 65, ce n'est plus nécessaire. Au lieu de cela, lancez le navigateur avec le drapeau de l'utilisation --Disable-dev-shm: xxx

Cela écrira des fichiers de mémoire partagés dans / TMP au lieu de / dev / shm.

J'espère cette aide.


0 commentaires

0
votes

Il est possible d'utiliser la fonctionnalité de guérison automatique Kubettes sans créer de cluster Kubettes à pleine échelle. Il est seulement nécessaire d'installer des versions compatibles de docker code> et kubelet code>. Il pourrait être utile d'installer kubeadm code> également.

Kubelet est la partie de Kubettes Control-avion qui prend soin de conserver PODS en état de santé. Il fonctionne comme un service SystemD et crée Pods statiques Utilisation de fichiers manifestes YAML de / etc / kubernettes / manifestes code> (l'emplacement est configurable). P>

Tout autre dépannage de l'application peut être effectué à l'aide de commandes Docker régulières: p> xxx pré>

a bon exemple de cette approche de la documentation officielle est Exécution d'instances externes et de grappes externes. (Remarque: la partie de configuration de Kubelet peut ne pas fonctionner comme prévu avec des versions de Kubelet récentes. J'ai mis plus de détails sur cela ci-dessous.) P>

aussi kubelet peut également prendre soin de l'utilisation des ressources de POD en appliquant Limits Partie d'une spécification de pod. Donc, vous pouvez définir la limite de mémoire et lorsque le conteneur atteindra cette limite Kubelet le redémarrera. P>

Kubelet peut faire une vérification de la demande de la demande dans la POD, si la section Sonde de la vigueur est incluse dans la spécification POD. . Si vous pouvez créer une commande pour vérifier la condition de votre application plus précisément, Kubelet peut redémarrer le conteneur lorsque la commande renvoie plusieurs fois le code de sortie non nuls dans une rangée (configurable). P>

Si Kubelet refuse de commencer, vous peut vérifier les journaux de kubelet à l'aide de la commande suivante: p>

systemctl daemon-reload
systemctl restart docker
systemctl restart kubelet
  • absence de kubelet initial config. Il peut être généré à l'aide de la commande kubeadm: kubelet kubelet kubelet-start-start-start code>. (Vous devrez peut-être aussi générer un certificat CA /etc/kubernettes/pki/ca.crt mentionné dans la configuration de Kubelet. Il peut être fait à l'aide de Kubadm: Kubeadm Init Phase Cert Ca Code>) P>

  • Paramètres de pilote différents de Cgroups pour Docker et Kubelet. Kubelet fonctionne bien avec des pilotes Cgroupsfs et SystemD. Le pilote par défaut Docker est cgroupfs. Kubeamd génère également une configuration Kubelet avec Cgroupsfs Driver, alors assurez-vous simplement qu'ils sont les mêmes. Docker Cgroups Pilote peut être spécifié dans le fichier de définition de service, par exemple /lib/systemd/system/docker.service code> ou /usr/lib/systemd/system/docker.service code> : p> XXX PRE> LI> ul>

    Pour modifier le pilote CGRoups pour la version de Kubelet récente, il est nécessaire de spécifier le fichier de configuration de Kubelet pour le service, car de telles options de ligne de commande sont désormais obsolètes: P>

    address: 127.0.0.1                           # changed, was 0.0.0.0
    apiVersion: kubelet.config.k8s.io/v1beta1
    authentication:
      anonymous:
        enabled: false
      webhook:
        cacheTTL: 2m0s
        enabled: false                           # changed, was true
      x509:
        clientCAFile: /etc/kubernetes/pki/ca.crt  # kubeadm init phase certs ca
    authorization:
      mode: AlwaysAllow                          # changed, was Webhook
      webhook:
        cacheAuthorizedTTL: 5m0s
        cacheUnauthorizedTTL: 30s
    cgroupDriver: cgroupfs                       # could be changed to systemd or left as is, as docker default driver is cgroupfs
    cgroupsPerQOS: true
    clusterDNS:
    - 10.96.0.10
    clusterDomain: cluster.local
    configMapAndSecretChangeDetectionStrategy: Watch
    containerLogMaxFiles: 5
    containerLogMaxSize: 10Mi
    contentType: application/vnd.kubernetes.protobuf
    cpuCFSQuota: true
    cpuCFSQuotaPeriod: 100ms
    cpuManagerPolicy: none
    cpuManagerReconcilePeriod: 10s
    enableControllerAttachDetach: true
    enableDebuggingHandlers: true
    enforceNodeAllocatable:
    - pods
    eventBurst: 10
    eventRecordQPS: 5
    evictionHard:
      imagefs.available: 15%
      memory.available: 100Mi
      nodefs.available: 10%
      nodefs.inodesFree: 5%
    evictionPressureTransitionPeriod: 5m0s
    failSwapOn: true
    fileCheckFrequency: 20s
    hairpinMode: promiscuous-bridge
    healthzBindAddress: 127.0.0.1
    healthzPort: 10248
    httpCheckFrequency: 20s
    imageGCHighThresholdPercent: 85
    imageGCLowThresholdPercent: 80
    imageMinimumGCAge: 2m0s
    iptablesDropBit: 15
    iptablesMasqueradeBit: 14
    kind: KubeletConfiguration
    kubeAPIBurst: 10
    kubeAPIQPS: 5
    makeIPTablesUtilChains: true
    maxOpenFiles: 1000000
    maxPods: 110
    nodeLeaseDurationSeconds: 40
    nodeStatusReportFrequency: 1m0s
    nodeStatusUpdateFrequency: 10s
    oomScoreAdj: -999
    podPidsLimit: -1
    port: 10250
    registryBurst: 10
    registryPullQPS: 5
    resolvConf: /etc/resolv.conf
    rotateCertificates: true
    runtimeRequestTimeout: 2m0s
    serializeImagePulls: true
    staticPodPath: /etc/kubernetes/manifests
    streamingConnectionIdleTimeout: 4h0m0s
    syncFrequency: 1m0s
    volumeStatsAggPeriod: 1m0s
    


0 commentaires