修改kubeadm的默认配置
kubeadm的初始化控制平面（init）命令和加入节点（join）命令均可以通过指定的配置文件修改默认参数的值。kubeadm将配置文件以ConfigMap形式保存到集群中，便于后续的查询和升级工作。kubeadm config子命令提供了对这组功能的支持。
- kubeadm config print init-defaults：输出kubeadm init命令默认参数的内容。
- kubeadm config print join-defaults：输出kubeadm join命令默认参数的内容。
- kubeadm config migrate：在新旧版本之间进行配置转换。
- kubeadm config images list：列出所需的镜像列表。
- kubeadm config images pull：拉取镜像到本地。
kubeadm config print init-defaults >init-default.yaml
对生成的文件进行编辑，可以按需生成合适的配置。例如，若需要自定义镜像的仓库地址、需要安装的Kubernetes版本号及Pod的IP地址范围
kubeadm config images list：列出所需的镜像列表
如果无法访问k8s.gcr.io，则可以使用国内镜像托管站点进行下载，例如https：//1nj0zren.mirror.aliyuncs.com，这可以通过修改Docker服务的配置文件（默认为/etc/docker/daemon.json）进行设置，例如：
然后，使用kubeadm config images pull命令或者docker pull命令下载上述镜像，
kubeadm config images pull --config=init-config.yaml
在镜像下载完成之后，就可以进行安装了。
在开始之前需要注意：kubeadm的安装过程不涉及网络插件（CNI）的初始化，因此kubeadm初步安装完成的集群不具备网络功能，任何Pod（包括自带的CoreDNS）都无法正常工作。而网络插件的安装往往对kubeadm init命令的参数有一定要求
创建和使用命令行插件
为了扩展kubectl的功能，Kubernetes从1.8版本开始引入插件机制，在1.14版本时达到稳定版。
用户自定义插件的可执行文件名需要以“kubectl-”开头，复制到$PATH中的某个目录（如/usr/local/bin）下，然后就可以通过kubectl <plugin-name>运行自定义插件了。
例如，通过Shell脚本实现一个名为hello的插件，其功能为在屏幕上输出字符串“hello world”。创建名为“kubectl-hello”的Shell脚本文件
通过插件机制，可以将某些复杂的kubectl命令简化为运行插件的方式。例如想创建一个命令来查看当前上下文环境（context）中的用户名，则可以通过kubectl config view命令进行查看
使用kubectl plugin list命令可以查看当前系统中已安装的插件列表
Pod深入了解
pod生命周期和重启策略
Pod在整个生命周期中被系统定义为各种状态
pod的创建过程
-
用户通过kubectl或其他api客户端提交需要创建的pod信息给apiServer
-
apiServer开始生成pod对象的信息，并将信息存入etcd，然后返回确认信息至客户端
-
apiServer开始反映etcd中的pod对象的变化，其它组件使用watch机制来跟踪检查apiServer上的变动
-
scheduler发现有新的pod对象要创建，开始为Pod分配主机并将结果信息更新至apiServer
-
node节点上的kubelet发现有pod调度过来，尝试调用docker启动容器，并将结果回送至apiServer
-
apiServer将接收到的pod状态信息存入etcd中
pod的终止过程
- 用户向apiServer发送删除pod对象的命令
- apiServcer中的pod对象信息会随着时间的推移而更新，在宽限期内（默认30s），pod被视为dead
- 将pod标记为terminating状态
- kubelet在监控到pod对象转为terminating状态的同时启动pod关闭过程
- 端点控制器监控到pod对象的关闭行为时将其从所有匹配到此端点的service资源的端点列表中移除
- 如果当前pod对象定义了preStop钩子处理器，则在其标记为terminating后即会以同步的方式启动执行
- pod对象中的容器进程收到停止信号
- 宽限期结束后，若pod中还存在仍在运行的进程，那么pod对象会收到立即终止的信号
- kubelet请求apiServer将此pod资源的宽限期设置为0从而完成删除操作，此时pod对于用户已不可见
初始化容器
初始化容器是在pod的主容器启动之前要运行的容器，主要是做一些主容器的前置工作，它具有两大特征：
- 初始化容器必须运行完成直至结束，若某初始化容器运行失败，那么kubernetes需要重启它直到成功完成
- 初始化容器必须按照定义的顺序执行，当且仅当前一个成功之后，后面的一个才能运行
初始化容器有很多的应用场景，下面列出的是最常见的几个：
- 提供主容器镜像中不具备的工具程序或自定义代码
- 初始化容器要先于应用容器串行启动并运行完成，因此可用于延后应用容器的启动直至其依赖的条件得到满足
接下来做一个案例，模拟下面这个需求：
假设要以主容器来运行nginx，但是要求在运行nginx之前先要能够连接上mysql和redis所在服务器
(192.168.90.15)服务器的地址
apiVersion: v1 kind: Pod metadata: name: pod-initcontainer namespace: dev spec: containers: - name: main-container image: nginx:1.17.1 ports: - name: nginx-port containerPort: 80 initContainers: - name: test-mysql image: busybox:1.30 command: ['sh', '-c', 'until ping 192.168.90.14 -c 1 ; do echo waiting for mysql...; sleep 2; done;'] - name: test-redis image: busybox:1.30 command: ['sh', '-c', 'until ping 192.168.90.15 -c 1 ; do echo waiting for reids...; sleep 2; done;']
# 创建pod [root@k8s-master01 ~]# kubectl create -f pod-initcontainer.yaml pod/pod-initcontainer created # 查看pod状态 # 发现pod卡在启动第一个初始化容器过程中，后面的容器不会运行 root@k8s-master01 ~]# kubectl describe pod pod-initcontainer -n dev ........ Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 49s default-scheduler Successfully assigned dev/pod-initcontainer to node1 Normal Pulled 48s kubelet, node1 Container image "busybox:1.30" already present on machine Normal Created 48s kubelet, node1 Created container test-mysql Normal Started 48s kubelet, node1 Started container test-mysql # 动态查看pod [root@k8s-master01 ~]# kubectl get pods pod-initcontainer -n dev -w NAME READY STATUS RESTARTS AGE pod-initcontainer 0/1 Init:0/2 0 15s pod-initcontainer 0/1 Init:1/2 0 52s pod-initcontainer 0/1 Init:1/2 0 53s pod-initcontainer 0/1 PodInitializing 0 89s pod-initcontainer 1/1 Running 0 90s # 接下来新开一个shell，为当前服务器新增两个ip，观察pod的变化 [root@k8s-master01 ~]# ifconfig ens33:1 192.168.90.14 netmask 255.255.255.0 up [root@k8s-master01 ~]# ifconfig ens33:2 192.168.90.15 netmask 255.255.255.0 up