The feature you've described is called Static Pods. Here is a part of documentation that describes their behaviour.
Static pods are managed directly by kubelet daemon on a specific node,
without the API server observing it. It does not have an associated
replication controller, and kubelet daemon itself watches it and
restarts it when it crashes. There is no health check. Static pods are
always bound to one kubelet daemon and always run on the same node
with it.
Kubelet automatically tries to create a mirror pod on the Kubernetes
API server for each static pod. This means that the pods are visible
on the API server but cannot be controlled from there.
The configuration files are just standard pod definitions in json or
yaml format in a specific directory. Use kubelet
--pod-manifest-path=<the directory> to start kubelet daemon, which periodically scans the directory and creates/deletes static pods as
yaml/json files appear/disappear there. Note that kubelet will ignore
files starting with dots when scanning the specified directory.
When kubelet starts, it automatically starts all pods defined in
directory specified in --pod-manifest-path= or --manifest-url=
arguments, i.e. our static-web.
Usually, those manifests are stored in the directory /etc/kubernetes/manifests.
If you put any changes to any of those manifests, that resource will be adjusted just like if you would run kubectl apply -f something.yaml command.
