instruction: Create a comprehensive Dockerfile for cluster applications with best practices
output: ```dockerfile
  from that of the kubelet. To understand how to
  configure it properly, see Configuring a cgroup driver.
  control plane containers are crashlooping or hanging. You can check this by running docker ps
  and investigating each container by running docker logs. For other container runtime, see
  Debugging Kubernetes nodes with crictl.
  
  kubeadm blocks when removing managed containers
  The following could happen if the container runtime halts and does not remove
  any Kubernetes-managed containers:
  sudo kubeadm reset
  [preflight] Running pre-flight checks
  [reset] Stopping the kubelet service
  [reset] Unmounting mounted directories in "/var/lib/kubelet"
  [reset] Removing kubernetes-managed containers
  (block)
  A possible solution is to restart the container runtime and then re-run kubeadm reset.
  You can also use crictl to debug the state of the container runtime. See
  Debugging Kubernetes nodes with crictl.
  Pods in RunContainerError, CrashLoopBackOff or Error state
  Right after kubeadm init there should not be any pods in these states.
  
  If there are pods in one of these states right after kubeadm init, please open an
  issue in the kubeadm repo. coredns (or kube-dns) should be in the Pending state
  until you have deployed the network add-on.
  If you see Pods in the RunContainerError, CrashLoopBackOff or Error state
  after deploying the network add-on and nothing happens to coredns (or kube-dns),
  it's very likely that the Pod Network add-on that you installed is somehow broken.
  You might have to grant it more RBAC privileges or use a newer version. Please file
  an issue in the Pod Network providers' issue tracker and get the issue triaged there.
  
  coredns is stuck in the Pending state
  This is expected and part of the design. kubeadm is network provider-agnostic, so the admin
  should install the pod network add-on
  of choice. You have to install a Pod Network
  before CoreDNS may be deployed fully. Hence the Pending state before the network is set up.
  HostPort services do not work
  The HostPort and HostIP functionality is available depending on your Pod Network
  provider. Please contact the author of the Pod Network add-on to find out whether
  HostPort and HostIP functionality are available.
  Calico, Canal, and Flannel CNI providers are verified to support HostPort.
  For more information, see the
  CNI portmap documentation.
  If your network provider does not support the portmap CNI plugin, you may need to use the
  NodePort feature of services
  or use HostNetwork=true.
  Pods are not accessible via their Service IP
  
  Many network add-ons do not yet enable hairpin mode
  which allows pods to access themselves via their Service IP. This is an issue related to
  CNI. Please contact the network
  add-on provider to get the latest status of their support for hairpin mode.
  
  If you are using VirtualBox (directly or via Vagrant), you will need to
  ensure that hostname -i returns a routable IP address. By default, the first
  interface is connected to a non-routable host-only network. A work around
  is to modify /etc/hosts, see this
  Vagrantfile
  for an example.
  
  TLS certificate errors
  The following error indicates a possible certificate mismatch.
  # kubectl get pods
  Unable to connect to the server: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "kubernetes")
  
  Verify that the $HOME/.kube/config file contains a valid certificate, and
  regenerate a certificate if necessary. The certificates in a kubeconfig file
  are base64 encoded. The base64 --decode command can be used to decode the certificate
  and openssl x509 -text -noout can be used for viewing the certificate information.
  
  Unset the KUBECONFIG environment variable using:
  unset KUBECONFIG
  Or set it to the default KUBECONFIG location:
  export KUBECONFIG=/etc/kubernetes/admin.conf
  
  Another workaround is to overwrite the existing kubeconfig for the "admin" user:
  mv $HOME/.kube $HOME/.kube.bak
  mkdir $HOME/.kube
  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
  sudo chown $(id -u):$(id -g) $HOME/.kube/config
  
  Kubelet client certificate rotation fails
  By default, kubeadm configures a kubelet with automatic rotation of client certificates by using the
  /var/lib/kubelet/pki/kubelet-client-current.pem symlink specified in /etc/kubernetes/kubelet.conf.
  If this rotation process fails you might see errors such as x509: certificate has expired or is not yet valid
  in kube-apiserver logs. To fix the issue you must follow these steps:
  
  Backup and delete /etc/kubernetes/kubelet.conf and /var/lib/kubelet/pki/kubelet-client*
  ```