无法获取我的kubernetes主节点的externalID(即aws提供的instanceId)

时间:2019-08-27 14:27:41

标签: kubernetes kubeadm amazon-eks aws-eks

我确实尝试过kubectl 描述节点masterNodeName ,它的输出为:-

Name:               ip-172-28-3-142
    Roles:              master
    Labels:             beta.kubernetes.io/arch=amd64
                        beta.kubernetes.io/os=linux
                        kubernetes.io/arch=amd64
                        kubernetes.io/hostname=ip-172-28-3-142
                        kubernetes.io/os=linux
                        node-role.kubernetes.io/master=
    Annotations:        kubeadm.alpha.kubernetes.io/cri-socket: /var/run/dockershim.sock
                        node.alpha.kubernetes.io/ttl: 0
                        projectcalico.org/IPv4Address: 172.28.3.142/20
                        projectcalico.org/IPv4IPIPTunnelAddr: 192.163.119.24
                        volumes.kubernetes.io/controller-managed-attach-detach: true
    CreationTimestamp:  Thu, 06 Jun 2019 04:10:28 +0000
    Taints:             <none>
    Unschedulable:      false
    Conditions:
      Type                 Status  LastHeartbeatTime                 LastTransitionTime                Reason                       Message
      ----                 ------  -----------------                 ------------------                ------                       -------
      NetworkUnavailable   False   Sat, 24 Aug 2019 12:10:03 +0000   Sat, 24 Aug 2019 12:10:03 +0000   CalicoIsUp                   Calico is running on this node
      MemoryPressure       False   Tue, 27 Aug 2019 14:08:19 +0000   Tue, 11 Jun 2019 14:38:27 +0000   KubeletHasSufficientMemory   kubelet has sufficient memory available
      DiskPressure         False   Tue, 27 Aug 2019 14:08:19 +0000   Tue, 11 Jun 2019 14:38:27 +0000   KubeletHasNoDiskPressure     kubelet has no disk pressure
      PIDPressure          False   Tue, 27 Aug 2019 14:08:19 +0000   Tue, 11 Jun 2019 14:38:27 +0000   KubeletHasSufficientPID      kubelet has sufficient PID available
      Ready                True    Tue, 27 Aug 2019 14:08:19 +0000   Tue, 11 Jun 2019 14:38:27 +0000   KubeletReady                 kubelet is posting ready status. AppArmor enabled
    Addresses:
      InternalIP:  172.28.3.142
      Hostname:    ip-172-28-3-142
    Capacity:
     cpu:                8
     ephemeral-storage:  20263484Ki
     hugepages-1Gi:      0
     hugepages-2Mi:      0
     memory:             32665856Ki
     pods:               110
    Allocatable:
     cpu:                8
     ephemeral-storage:  18674826824
     hugepages-1Gi:      0
     hugepages-2Mi:      0
     memory:             32563456Ki
     pods:               110
    System Info:
     Machine ID:                 121a679a217040c4aed637a6dc1e0582
     System UUID:                EB219C6D-8C25-AC92-9676-D6B04770257A
     Boot ID:                    144b1dt4-faf8-4fcb-229a-51082410bc5e
     Kernel Version:             4.15.0-2043-aws
               Namespace                  Name                                         CPU Requests  CPU Limits  Memory Requests   

编辑:-我正在使用kubeadm在aws EC2实例上设置Kubernetes。

我正在寻找一种在实例配置中将InstanceID作为externalID的方法。

我的V1Node类群集信息也为空

3 个答案:

答案 0 :(得分:2)

从1.1开始,

ExternalIDdeprecated

不幸的是,您无法在版本1.11的finally cleaned版本中获得它。

唯一的方法是回滚/反向更改所做的更改并构建自己的版本。

答案 1 :(得分:1)

在ec2节点上添加集群名称标签,标签的值无关紧要,只有名称才重要。例如

kubernetes.io/cluster/CLUSTER_NAME

kubernetes.io/cluster/dhanvi-test-cluster

确保按照https://github.com/kubernetes/cloud-provider-aws#iam-policy

所述设置IAM策略。

使用以下配置文件,将kubeadm用作kubeadm init --config FILE_NAME.yaml

---
apiVersion: kubeadm.k8s.io/v1beta2
kind: ClusterConfiguration
apiServer:
  extraArgs:
    cloud-provider: aws
clusterName: dhanvi-test-cluster
controllerManager:
  extraArgs:
    cloud-provider: aws
kubernetesVersion: stable

---
apiVersion: kubeadm.k8s.io/v1beta2
kind: InitConfiguration
nodeRegistration:
  kubeletExtraArgs:
    cloud-provider: aws

理想地,通过执行上述操作,您应该能够在描述节点时获得providerID,它也应该为您提供群集名称。

如果仍然缺少providerID作为解决方法,则仍可以编辑节点并手动添加它。

即使在extraArgs中提供了云提供商之后,如果您仍未获得providerID,请考虑在https://github.com/kubernetes/kubeadm/issues提出问题。

答案 2 :(得分:0)

Tummala Dhanvi说的是正确的,但是这里有更多细节。

如果您使用EKSGKE(我不确定其他),则它们有一个重要的共同点。它们都由云管理。这样做主要是为了使Kubernetes更加易于使用,因此您只需对将在集群上运行的应用程序负责,而不必理会集群的所有配置。

这还可以使您的Kubernetes集群始终可访问,因为默认情况下云将检测并替换不正常的控制平面节点并提供按需升级和修补,并确保工作节点和托管控制平面之间的加密连接安全。 / p>

您可以访问辅助节点,这在GKE和EKS中都是可能的,但您将无权访问主节点。

如果要完全访问主节点和工作节点,则需要自己部署Kubernetes。 如果您已经准备好虚拟机,这将非常简单直接。

您可以为此使用kubeadm并创建a single control-plane clusterHighly Available cluster

还有kopskubespray之类的其他工具可以为您完成集群安装。

请阅读Picking the Right Solution以在各种平台上运行Kubernetes,这是选择适合您需求的解决方案的指南。