错误:服务器没有资源类型“ svc”

时间:2018-07-12 14:32:56

标签: kubernetes kubectl amazon-eks

在遵循本指南的同时测试error: the server doesn't have a resource type "svc"的配置时获取kubectl

https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html

详细错误

$ kubectl get svc -v=8

I0712 15:30:24.902035   93745 loader.go:357] Config loaded from file /Users/matt.canty/.kube/config-test
I0712 15:30:24.902741   93745 round_trippers.go:383] GET https://REDACTED.yl4.us-east-1.eks.amazonaws.com/api
I0712 15:30:24.902762   93745 round_trippers.go:390] Request Headers:
I0712 15:30:24.902768   93745 round_trippers.go:393]     User-Agent: kubectl/v1.10.3 (darwin/amd64) kubernetes/2bba012
I0712 15:30:24.902773   93745 round_trippers.go:393]     Accept: application/json, */*
I0712 15:30:25.425614   93745 round_trippers.go:408] Response Status: 401 Unauthorized in 522 milliseconds
I0712 15:30:25.425651   93745 round_trippers.go:411] Response Headers:
I0712 15:30:25.425657   93745 round_trippers.go:414]     Content-Type: application/json
I0712 15:30:25.425662   93745 round_trippers.go:414]     Content-Length: 129
I0712 15:30:25.425670   93745 round_trippers.go:414]     Date: Thu, 12 Jul 2018 14:30:25 GMT
I0712 15:30:25.426757   93745 request.go:874] Response Body: {"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure","message":"Unauthorized","reason":"Unauthorized","code":401}
I0712 15:30:25.428104   93745 cached_discovery.go:124] skipped caching discovery info due to Unauthorized
I0712 15:30:25.428239   93745 round_trippers.go:383] GET https://REDACTED.yl4.us-east-1.eks.amazonaws.com/api
I0712 15:30:25.428258   93745 round_trippers.go:390] Request Headers:
I0712 15:30:25.428268   93745 round_trippers.go:393]     Accept: application/json, */*
I0712 15:30:25.428278   93745 round_trippers.go:393]     User-Agent: kubectl/v1.10.3 (darwin/amd64) kubernetes/2bba012
I0712 15:30:25.577788   93745 round_trippers.go:408] Response Status: 401 Unauthorized in 149 milliseconds
I0712 15:30:25.577818   93745 round_trippers.go:411] Response Headers:
I0712 15:30:25.577838   93745 round_trippers.go:414]     Content-Type: application/json
I0712 15:30:25.577854   93745 round_trippers.go:414]     Content-Length: 129
I0712 15:30:25.577868   93745 round_trippers.go:414]     Date: Thu, 12 Jul 2018 14:30:25 GMT
I0712 15:30:25.578876   93745 request.go:874] Response Body: {"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure","message":"Unauthorized","reason":"Unauthorized","code":401}
I0712 15:30:25.579492   93745 cached_discovery.go:124] skipped caching discovery info due to Unauthorized
I0712 15:30:25.579851   93745 round_trippers.go:383] GET https://REDACTED.yl4.us-east-1.eks.amazonaws.com/api
I0712 15:30:25.579864   93745 round_trippers.go:390] Request Headers:
I0712 15:30:25.579873   93745 round_trippers.go:393]     Accept: application/json, */*
I0712 15:30:25.579879   93745 round_trippers.go:393]     User-Agent: kubectl/v1.10.3 (darwin/amd64) kubernetes/2bba012
I0712 15:30:25.729513   93745 round_trippers.go:408] Response Status: 401 Unauthorized in 149 milliseconds
I0712 15:30:25.729541   93745 round_trippers.go:411] Response Headers:
I0712 15:30:25.729547   93745 round_trippers.go:414]     Content-Type: application/json
I0712 15:30:25.729552   93745 round_trippers.go:414]     Content-Length: 129
I0712 15:30:25.729557   93745 round_trippers.go:414]     Date: Thu, 12 Jul 2018 14:30:25 GMT
I0712 15:30:25.730606   93745 request.go:874] Response Body: {"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure","message":"Unauthorized","reason":"Unauthorized","code":401}
I0712 15:30:25.731228   93745 cached_discovery.go:124] skipped caching discovery info due to Unauthorized
I0712 15:30:25.731254   93745 factory_object_mapping.go:93] Unable to retrieve API resources, falling back to hardcoded types: Unauthorized
F0712 15:30:25.731493   93745 helpers.go:119] error: the server doesn't have a resource type "svc"

AWS中的EKS群集截图

enter image description here

版本

kubectl version

Client Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.3", GitCommit:"2bba0127d85d5a46ab4b778548be28623b32d0b0", GitTreeState:"clean", BuildDate:"2018-05-28T20:03:09Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"darwin/amd64"}
error: You must be logged in to the server (the server has asked for the client to provide credentials)

配置

Kubctl配置

$ kubectl config view

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: REDACTED
    server: https://REDACTED.yl4.us-east-1.eks.amazonaws.com
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    user: aws
  name: aws
current-context: aws
kind: Config
preferences: {}
users:
- name: aws
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1alpha1
      args:
      - token
      - -i
      - test
      command: heptio-authenticator-aws
      env:
      - name: AWS_PROFILE
        value: personal

AWS配置

cat .aws/config

[profile personal]
source_profile = personal 

AWS凭证

$ cat .aws/credentials

[personal]
aws_access_key_id = REDACTED
aws_secret_access_key = REDACTED

〜/ .kube / config-test

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: REDACETED
    server: https://REDACTED.yl4.us-east-1.eks.amazonaws.com
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    user: aws
  name: aws
current-context: aws
kind: Config
preferences: {}
users:
- name: aws
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1alpha1
      args:
      - token
      - -i
      - test
      command: heptio-authenticator-aws
      env:
      - name: AWS_PROFILE
        value: personal

类似问题

8 个答案:

答案 0 :(得分:4)

我遇到了类似的问题,并通过AWS支持得以解决。我遇到的问题是,群集是使用用户承担的角色创建的,但kubectl并未使用aws-cli创建的默认kube配置承担该角色。

我通过在kube config的users部分提供角色来解决了该问题

users:
- name: aws
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1alpha1
      args:
      - token
      - -i
      - test
      - -r
      - <arn::of::your::role>
      command: aws-iam-authenticator
      env:
      - name: AWS_PROFILE
        value: personal

我相信heptio-aws-authenticator现在已更改为aws-iam-authenticator,但是这一更改使我得以使用集群。

答案 1 :(得分:3)

401s看起来像是权限问题。您的用户创建集群了吗? 在文档中:“创建Amazon EKS集群时,会在集群的RBAC配置中自动为IAM实体(用户或角色)授予system:master权限。要授予其他AWS用户与集群交互的能力,您必须进行编辑Kubernetes中的aws-auth ConfigMap。”

如果它是由其他用户创建的,则需要使用该用户,并在CLI中对其进行配置以执行kubectl

答案 2 :(得分:2)

只需删除.kube文件夹中的缓存和http-cache并尝试运行命令 kubectl获得服务 还要确保您的配置文件正确缩进。由于语法错误,有时可能会引发该错误。

答案 3 :(得分:2)

需要确保在CLI中用于创建集群和执行kubectl的凭据相同。在我的情况下,我通过控制台创建了集群,该集群采用了已过期的AWS临时自动售货机凭证,而kubectl则使用了实际的永久凭证。
为了解决该错误,我也从AWS CLI创建了集群。

答案 4 :(得分:1)

我遇到了这个问题,我的KUBECONFIG环境变量具有多个值,它看起来像: :/Users/my-user/.kube/config-firstcluster:/Users/my-user/.kube/config-secondcluster

尝试将环境变量设置为零并将其重置为仅1个值,看看是否对您有用。

答案 5 :(得分:0)

我遇到了这个错误,它是一个 DIFFERENT 的kube配置问题,所以

error: the server doesn't have a resource type “svc”

错误可能非常普遍。

就我而言,解决方案是删除证书授权数据周围的引号

示例

(不起作用)

certificate-authority-data:"xyxyxyxyxyxy"

(工作中)

certificate-authority-data: xyxyxyxyxyxy

答案 6 :(得分:0)

可能的解决方案,如果您在UI中创建了群集

如果您在UI中创建了集群,则AWS root用户可以创建集群。根据文档,“创建Amazon EKS集群时,创建集群的IAM实体(用户或角色)将以管理员(具有system:master)权限添加到Kubernetes RBAC授权表中。最初,仅该IAM用户可以使用kubectl调用Kubernetes API服务器。“

您需要首先以root用户身份登录到AWS CLI,以更新您想要访问集群的IAM用户的权限。

  1. 您需要获取一个access key for the root user并将此信息放入默认用户下的.aws/credentials中。您可以使用命令aws configure

    现在kubectl get svc可以工作了,因为您以最初创建集群的root用户身份登录。

  2. Apply the aws-auth ConfigMap to the cluster。按照这些文档中的步骤2进行操作,使用从Step 3: Launch and Configure Amazon EKS Worker Nodes

  3. 获得的NodeInstanceRole作为Output
  4. To add a non-root IAM user or role to an Amazon EKS cluster,请按照这些文档中的步骤3进行操作。 编辑configmap/aws-auth,并在kubectl部分中添加其他需要mapUsers访问权限的用户。

  5. 再次运行aws configure并添加非root用户的访问密钥信息。

现在,您可以从AWS CLI并使用kubectl访问集群。

答案 7 :(得分:0)

我遇到了类似的问题,即无法使用yourEditText.setVisibility(View.GONE); //To hide it yourEditText.setVisibility(View.VISIBLE); //To show it 列出任何kubernetes对象。我尝试了以下命令,但是遇到了同样的“错误:服务器没有资源类型kubectl

object_name

我检查了k8s仪表板,它对我来说很好用。因此,我了解到 kubectl 试图与 kube-apiserver 建立连接时会出现问题。我决定使用现有证书kubectl get pod kubectl get service kubectl get configmap kubectl get namespace apiserver,但是它需要证书密钥和crt文件。默认情况下,kubectl从curl中读取配置并查找上下文。如果有多个群集,请检查$HOME/.kube/config的值。在current-context: your_user@cluster_name部分中,检查users并按照以下步骤将your_userclient-certificate/client-certificate-data的值保存在文件中。

client-key/client-key-data

如果证书已过期,请创建一个新证书并尝试进行身份验证

echo "value of client-certificate-data" | base64 --decode > your_user.crt
echo "value of client-key-data" | base64 --decode > your_user.key

#check the validality of certificate
openssl x509 -in your_user.crt -text 

如果您能够看到Pod,请在配置文件中更新证书

$ HOME / .kube / config的最终输出

openssl genrsa -out your_user.key 2048
openssl req -new -key your_user.key -subj "/CN=check_cn_from_existing_certificate_crt_file" -out your_user.csr
openssl x509 -req -in your_user.csr -CA /$PATH/ca.crt -CAkey /$PATH/ca.key -out your_user.crt -days 30

# Get the apiserver ip
APISERVER=$(cat ~/.kube/config | grep server | cut -f 2- -d ":" | tr -d " ")

# Authenticate with apiserver using curl command
curl $APISERVER/api/v1/pods \
            --cert your_user.crt \
            --key your_user.key \
            --cacert /$PATH/ca.crt

现在,您应该能够使用apiVersion: v1 clusters: - cluster: certificate-authority: /$PATH/ca.crt server: https://192.168.0.143:8443 ($APISERVER) name: cluster_name contexts: - context: cluster: cluster_name user: your_user name: your_user@cluster_name current-context: your_user@cluster_name kind: Config preferences: {} users: - name: your_user user: client-certificate: /$PATH/your_user.crt client-key: /$PATH/your_user.key

成功列出pod或其他资源