如何调试kubectl申请kube-flannel.yml？

Question

我正在尝试按照以下文档创建一个kubernetes集群:https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/

首先,我在VirtualBox中使用Vagrant在Coreos(1520.9.0)上安装了带有docker镜像的kubeadm:

docker run -it \
    -v /etc:/rootfs/etc \
    -v /opt:/rootfs/opt \
    -v /usr/bin:/rootfs/usr/bin \
    -e K8S_VERSION=v1.8.4 \
    -e CNI_RELEASE=v0.6.0 \
    xakra/kubeadm-installer:0.4.7 coreos

这是我的kubeadm init:

kubeadm init --pod-network-cidr=10.244.0.0/16

运行命令时:

kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/v0.9.1/Documentation/kube-flannel.yml

它返回:

clusterrole "flannel" configured
clusterrolebinding "flannel" configured
serviceaccount "flannel" configured
configmap "kube-flannel-cfg" configured
daemonset "kube-flannel-ds" configured

但如果我检查"kubectl get pods --all-namespaces"

它返回:

NAMESPACE     NAME                              READY     STATUS             RESTARTS   AGE
kube-system   etcd-coreos1                      1/1       Running            0          18m
kube-system   kube-apiserver-coreos1            1/1       Running            0          18m
kube-system   kube-controller-manager-coreos1   0/1       CrashLoopBackOff   8          19m
kube-system   kube-scheduler-coreos1            1/1       Running            0          18m

随着journalctl -f -u kubelet我可以看到这个错误:Unable to update cni config: No networks found in /etc/cni/net.d

我怀疑这个命令有问题 kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/v0.9.1/Documentation/kube-flannel.yml

有没有办法知道为什么这个命令不起作用？我可以从任何地方获取一些日志吗？

Answer 1

就在今晚，我使用kubespray在 CoreOS 上使用 flannel (vxlan) 配置了一个 vagrant 集群，而且我也对 flannel 如何成为 Kubernetes 中的 Pod 感到困惑

事实证明，正如这里所看到的，他们正在使用来自 quay.io 的flannel-cni映像，并使用 flannel side-car 和 hostDir 卷挂载来写出 CNI 文件；它输出（配置 CNI 使用 flannel），然后（配置 flannel 使用的子网和后端）。cni-conf.jsonnet-conf.json

我希望 jinja2 Mustache 语法不会混淆答案，但我发现看到 Kubernetes 人们如何选择“真正”地这样做来与DaemonSetflannel-cni README 中给出的示例进行比较和对比是非常有趣的。我想这就是长话短说：尝试 flannel-cni 自述文件中的描述符，然后如果它不起作用，看看它们是否在某些方面与已知工作的 kubespray 设置不同

更新：作为一个具体示例，请注意文档 yaml不包含--iface=开关，如果您的 Vagrant 设置同时使用 NAT 和“private_network”，那么它可能意味着 flannel 绑定到eth0（NAT 网络）而不是eth1更多静态IP。我看到文档中提到的警告，但无法立即回忆起在哪里引用它

更新2

有没有办法知道为什么这个命令不起作用？我可以从任何地方获取一些日志吗？

kube-controller-manager-coreos1人们几乎总是可以以相同的方式访问 Pod 的日志（即使是静态定义的，例如） kubectl --namespace=kube-system logs kube-controller-manager-coreos1，并且在 CrashLoopBackOff 情况下，添加 for -p“-p”revious 将显示最近一次崩溃的日志（但仅持续几秒钟，而不是无限期），并且偶尔kubectl --namespace=kube-system describe pod kube-controller-manager-coreos1会在底部的“事件”部分或顶部附近的“状态”块中显示有用的信息（如果因原因而终止）

如果出现非常严重的故障，例如 apiserver 无法启动（因此kubectl logs不会执行任何操作），则可以 ssh 到节点并使用journalctl -u kubelet.service --no-pager --lines=150和 的组合docker logs ${the_sha_or_name}来尝试查看任何错误文本。在后一种情况下，您几乎肯定需要docker ps -a找到退出容器的 sha 或名称，但同样的“仅几秒钟”也适用，因为死容器将在一段时间后被修剪。

对于 vagrant，可以通过以下几种方式之一 ssh 进入虚拟机：

• vagrant ssh coreos1
• vagrant ssh-config > ssh-config && ssh -F ssh-config coreos1
• 或者如果它有一个“private_network”地址，例如 192.168.99.101 等，那么通常可以，ssh -i ~/.vagrant.d/insecure_private_key core@192.168.99.101但前两个地址之一几乎总是更方便