在的二进制部署方式中，kubelet、etcd、kube-apiServer、kube-controller-manager、kube-scheduler组件均作为一项系统服务部署，服务配置文件位于/usr/lib/systemd/system/<object-name.service>，启动参数配置位于/etc/kubernetes/<object-name>。
而kubeadm作为致力于简化集群安装过程的工具，并不再把组件用上述服务注册启动的方式进行安装。
引用文章https://segmentfault.com/a/1190000018741112?utm_source=tag-newest 中对kubeadm部署原理的叙述:
kubeadm做了这些事
执行 kubeadm init时：
- 自动化的集群机器合规检查
- 自动化生成集群运行所需的各类证书及各类配置，并将Master节点信息保存在名为cluster-info的ConfigMap中。
- 通过static Pod方式，运行API server, controller manager 、scheduler及etcd组件。
- 生成Token以便其他节点加入集群
执行 kubeadm join时：
- 节点通过token访问kube-apiserver，获取cluster-info中信息，主要是apiserver的授权信息（节点信任集群）。
- 通过授权信息，kubelet可执行TLS bootstrapping，与apiserver真正建立互信任关系（集群信任节点）。
简单来说，kubeadm做的事就是把大部分组件都容器化，通过StaticPod方式运行，并自动化了大部分的集群配置及认证等工作，简单几步即可搭建一个可用Kubernetes的集群。
因此，kubeadm部署的K8s集群大部分组件都以容器的形式存在，在哪里可以发现他们呢?
在部署后的集群中，使用kubectl get Pods -A查看所有Pod
# kubectl get pods -A
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system coredns-5644d7b6d9-49v79 1/1 Running 15 17d
kube-system coredns-5644d7b6d9-w7fd5 1/1 Running 15 17d
kube-system etcd-miwifi-r4cm-srv 1/1 Running 81 17d
kube-system kube-apiserver-miwifi-r4cm-srv 1/1 Running 26 3d4h
kube-system kube-controller-manager-miwifi-r4cm-srv 1/1 Running 47 17d
kube-system kube-proxy-gk5bw 1/1 Running 16 17d
kube-system kube-proxy-lpbbl 1/1 Running 16 17d
kube-system kube-scheduler-miwifi-r4cm-srv 1/1 Running 44 17d
kube-system weave-net-c8hs6 2/2 Running 49 17d
kube-system weave-net-rbzcw 2/2 Running 25 6d7h
通过Pod名称的前缀。可以清楚的看到包括etcd、kube-apiserver、kube-controller-manager、kube-proxy、kube-scheduler和dns工具coredns、网络插件weave均以Pod的形式存在于名为kube-system的Namespace中。
我们可以通过修改一个普通容器的方式查看或修改上述组件的信息
kubectl edit pod <pod-name> -n <Namespace-name>
如运行# kubectl edit pod kube-proxy-lpbbl -n kube-system
当然，也可以通过kubectl logs命令看到各个组件的运行日志
# kubectl logs kube-proxy-lpbbl -n kube-system
W1222 14:40:33.120498 1 proxier.go:597] Failed to load kernel module ip_vs with modprobe. You can ignore this message when kube-proxy is running inside container without mounting /lib/modules
W1222 14:40:33.137374 1 proxier.go:597] Failed to load kernel module ip_vs_rr with modprobe. You can ignore this message when kube-proxy is running inside container without mounting /lib/modules
W1222 14:40:33.138451 1 proxier.go:597] Failed to load kernel module ip_vs_wrr with modprobe. You can ignore this message when kube-proxy is running inside container without mounting /lib/modules
W1222 14:40:33.155133 1 proxier.go:597] Failed to load kernel module ip_vs_sh with modprobe. You can ignore this message when kube-proxy is running inside container without mounting /lib/modules
W1222 14:40:33.163566 1 server_others.go:329] Flag proxy-mode="" unknown, assuming iptables proxy
I1222 14:40:33.196730 1 node.go:135] Successfully retrieved node IP: 192.168.31.189
I1222 14:40:33.196776 1 server_others.go:149] Using iptables Proxier.......
那么，上述容器组件Pod是以什么样的形式被定义的呢，他们的启动配置文件又在什么位置呢？
答案是静态Pod，所谓静态Pod，是指需要长期运行在固定Node上，不被控制器和API Server掌控的Pod。
静态Pod只能由各Node自定义，而不是由主结点调配。
关于静态Pod的更多信息，可以参考本人学习笔记https://blog.csdn.net/qq_38093301/article/details/103469288
适合需要持续运行的长期设施，上述K8s的基础设施组件正是被注册成为各节点上的静态Pod
找到静态Pod配置文件的默认目录，系统将自动按时扫描该目录，根据目录中的文件在本节点启动静态Pod。
目录位置：/etc/kubernetes/manifests
# ls /etc/kubernetes/manifests
etcd.yaml kube-apiserver.yaml kube-controller-manager.yaml kube-scheduler.yaml
可以看到四大组件的配置文件
具体查看一个文件，可以看到其配置信息和启动参数都在其中，我们当然可以修改这些文件来修改相关配置
# vim kube-scheduler.yaml
cheduler
tier: control-plane
name: kube-scheduler
namespace: kube-system
spec:
containers:
- command:
- 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......
由于kubelet在配置容器网络、管理容器数据卷时，都需要直接操作宿主机，而如果现在 kubelet 本身就运行在一个容器里，那么直接操作宿主机就会变得很麻烦，所以，kubelet并没有以上述方式部署。
kubelet配置文件位置在 /usr/lib/systemd/system/kubelet.service.d/10-kubeadm.conf
