首先

这个完全是个失败的故事。

前提條件

kubernetes 1.23 (masterはシングルノード)

搞砸的事情 (Yā de

我错误地部署了一个与kube-apiserver具有相同IP和端口的服务。
* 在单节点结构中，”10.0.0.1″是主节点（Kubernetes API服务器）的IP地址。

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  ports:
  - protocol: TCP
    port: 6443
    targetPort: 443
  externalIPs:
  - 10.0.0.1

策划并执行回复策略

这样一来，kube-apiserver的Pod会陷入重新启动的循环，导致无法使用kubectl。一开始我非常紧张，但由于应用程序的Pod仍然能够持续运行，所以我没有草率地操作，而是考虑了恢复方案。

由于重新启动循环，无法与API进行通信。另外，即使使用crictl尝试进入容器，容器ID也会改变，无法长时间进入。暂时放弃对kube-apiserver的访问，稍后再考虑。

由于我在Kubernetes上有一定程度的了解，所以我知道kube-apiserver的数据都存储在etcd中。因此，我尝试直接连接etcd来删除出现问题的Service资源。

连接到etcd需要使用一个名为etcdctl的命令。
由于kubernetes的etcd需要证书和密钥，因此需要提前查看静态Pod的清单。

# grep pki /etc/kubernetes/manifests/etcd.yaml
    - --cert-file=/etc/kubernetes/pki/etcd/server.crt
    - --key-file=/etc/kubernetes/pki/etcd/server.key
    - --peer-cert-file=/etc/kubernetes/pki/etcd/peer.crt
    - --peer-key-file=/etc/kubernetes/pki/etcd/peer.key
    - --peer-trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt
    - --trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt
    - mountPath: /etc/kubernetes/pki/etcd
      path: /etc/kubernetes/pki/etcd

据我所知，其中的”–cert-file”、”–key-file”和”-trusted-ca-file”是必需的。
你可以通过清单文件来确认目标端口号。

# grep advertise-client-urls /etc/kubernetes/manifests/etcd.yaml 
    kubeadm.kubernetes.io/etcd.advertise-client-urls: https://10.0.0.1:2379
    - --advertise-client-urls=https://10.0.0.1:2379

我将尝试连接到指定的连接目标和端口号。

# ETCDCTL_API=3 etcdctl endpoint status \
--endpoints=https://[127.0.0.1]:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key

https://[127.0.0.1]:2379, 63044e73c12f33cd, 3.5.1, 20 MB, true, 86, 270366839

看起来能够成功连接了，真是太好了。
我们来搜索一下出现问题的服务资源的键。以前好像有一个“list”的命令，但现在似乎改成了“get /”。

# ETCDCTL_API=3 etcdctl get / --prefix --keys-only \
--endpoints=https://[127.0.0.1]:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key \
 | grep my-service

毅然决然地删除键。

# ETCDCTL_API=3 etcdctl del '/registry/services/specs/default/my-service' \
--endpoints=https://[127.0.0.1]:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key

删除后，需要重新启动主节点。

# reboot

我认为单一的主节点只需简单地重新启动即可。这次我们通过这种方式成功地恢复了。

最后

我成功地只使用Service资源将Kubernetes操作变得无法进行！！即使在家里，也要小心管理员权限。
由于无法使用kubectl，对于管理车辆来说有相当大的影响，所以我认为这是一个很好的故障排除问题，适用于Kubernetes初学者。

在亚马逊 EKS 中，可以通过以下配置进行限制。

OpenShift的配置如下。