Как отлаживать неудачные вызовы kubectl?

Question

Как отлаживать неудачные вызовы kubectl?

Я на Suse 12.01 Enterprise и пытаюсь заставить работать Minikube. ВМ уже работает, и инструмент оболочки Minikube может общаться.

Но kubectl все еще не может говорить с мастером kubernetes. Я пытаюсь отладить это, и лучший способ получить дополнительную информацию, кажется, запустить случайную команду с -v 9, Делая это, я получаю следующий вывод:

$ kubectl get pots -v 9
I0310 14:02:27.727767   29330 loader.go:354] Config loaded from file /home/D069407/.kube/config
I0310 14:02:27.728479   29330 round_trippers.go:299] curl -k -v -XGET  -H "Accept: application/json, */*" -H "User-Agent: kubectl/v1.5.3 (linux/amd64) kubernetes/029c3a4" https://192.168.99.104:8443/api
I0310 14:03:42.704009   29330 round_trippers.go:318] GET https://192.168.99.104:8443/api  in 74975 milliseconds
I0310 14:03:42.704037   29330 round_trippers.go:324] Response Headers:
I0310 14:03:42.704103   29330 helpers.go:221] Connection error: Get https://192.168.99.104:8443/api: Service Unavailable
F0310 14:03:42.704111   29330 helpers.go:116] Unable to connect to the server: Service Unavailable

Не много информации, но я думаю, что curl -k -vvvv .... дал бы мне больше информации. Тем не менее, просто выполнение того же скручивания, что и в журнале, приводит к ошибке аутентификации, поскольку сервер API выполняет аутентификацию клиента (верно?). Так что это не работает.

Как я могу продолжить отладку сейчас? Есть ли секретный способ ниндзя дать параметры curl auth без добавления их в вызов оболочки? Действительно ли kubectl выполняет другой запрос и просто печатает локон в журнале, чтобы дать некоторые подсказки о том, что он вызывает?

* edit: Обсуждая с коллегой, мы оба согласились, что это внутренняя проблема minikube vm.

minikube logs начинаются так:

-- Logs begin at Fri 2017-03-10 12:43:34 UTC, end at Fri 2017-03-10 14:44:11 UTC. --
Mar 10 12:45:45 minikube systemd[1]: Starting Localkube...
Mar 10 12:45:45 minikube localkube[3496]: I0310 12:45:45.977140    3496 start.go:77] Feature gates:%!(EXTRA string=)
Mar 10 12:45:45 minikube localkube[3496]: localkube host ip address: 10.0.2.15
Mar 10 12:45:45 minikube localkube[3496]: I0310 12:45:45.981395    3496 server.go:215] Using iptables Proxier.
Mar 10 12:45:45 minikube localkube[3496]: W0310 12:45:45.981764    3496 server.go:468] Failed to retrieve node info: Get http://127.0.0.1:8080/api/v1/nodes/minikube: dial tcp 127.0.0.1:8080:
getsockopt: connection refused
Mar 10 12:45:45 minikube localkube[3496]: W0310 12:45:45.981879    3496 proxier.go:249] invalid nodeIP, initialize kube-proxy with 127.0.0.1 as nodeIP
Mar 10 12:45:45 minikube localkube[3496]: W0310 12:45:45.981947    3496 proxier.go:254] clusterCIDR not specified, unable to distinguish between internal and external traffic
Mar 10 12:45:45 minikube localkube[3496]: I0310 12:45:45.982082    3496 server.go:227] Tearing down userspace rules.
Mar 10 12:45:45 minikube localkube[3496]: Starting etcd...
Mar 10 12:45:45 minikube localkube[3496]: E0310 12:45:45.991070    3496 reflector.go:188] pkg/proxy/config/api.go:30: Failed to list *api.Service: Get http://127.0.0.1:8080/api/v1/services?r
esourceVersion=0: dial tcp 127.0.0.1:8080: getsockopt: connection refused
Mar 10 12:45:45 minikube localkube[3496]: E0310 12:45:45.991108    3496 reflector.go:188] pkg/proxy/config/api.go:33: Failed to list *api.Endpoints: Get http://127.0.0.1:8080/api/v1/endpoint
s?resourceVersion=0: dial tcp 127.0.0.1:8080: getsockopt: connection refused
Mar 10 12:45:45 minikube localkube[3496]: name = kubeetcd
Mar 10 12:45:45 minikube localkube[3496]: data dir = /var/lib/localkube/etcd
Mar 10 12:45:45 minikube localkube[3496]: member dir = /var/lib/localkube/etcd/member
Mar 10 12:45:45 minikube localkube[3496]: heartbeat = 100ms
Mar 10 12:45:45 minikube localkube[3496]: election = 1000ms
Mar 10 12:45:45 minikube localkube[3496]: snapshot count = 10000
Mar 10 12:45:45 minikube localkube[3496]: advertise client URLs = http://0.0.0.0:2379
Mar 10 12:45:45 minikube localkube[3496]: initial advertise peer URLs = http://0.0.0.0:2380
Mar 10 12:45:45 minikube localkube[3496]: initial cluster = kubeetcd=http://0.0.0.0:2380
Mar 10 12:45:45 minikube localkube[3496]: starting member fcf2ad36debdd5bb in cluster 7f055ae3b0912328
Mar 10 12:45:45 minikube localkube[3496]: fcf2ad36debdd5bb became follower at term 0
Mar 10 12:45:45 minikube localkube[3496]: newRaft fcf2ad36debdd5bb [peers: [], term: 0, commit: 0, applied: 0, lastindex: 0, lastterm: 0]
Mar 10 12:45:45 minikube localkube[3496]: fcf2ad36debdd5bb became follower at term 1
Mar 10 12:45:46 minikube localkube[3496]: starting server... [version: 3.0.14, cluster version: to_be_decided]
Mar 10 12:45:46 minikube localkube[3496]: Starting apiserver...
Mar 10 12:45:46 minikube localkube[3496]: Starting controller-manager...
Mar 10 12:45:46 minikube localkube[3496]: Starting scheduler...
Mar 10 12:45:46 minikube localkube[3496]: Starting kubelet...
Mar 10 12:45:46 minikube localkube[3496]: added member fcf2ad36debdd5bb [http://0.0.0.0:2380] to cluster 7f055ae3b0912328
Mar 10 12:45:46 minikube localkube[3496]: Starting proxy...
Mar 10 12:45:46 minikube localkube[3496]: Starting storage-provisioner...

внутри minikube ssh сервис API работает, хотя. Проверено с curl 127.0.0.1:8080/api и получать хороший JSON.

* редактировать: на основе обратной связи еще немного информации.

завить внутри миникуба вм:

$ curl localhost:8080
{
"paths": [
    "/api",
    "/api/v1",
    "/apis",
    "/apis/apps",
    "/apis/apps/v1beta1",
    "/apis/authentication.k8s.io",
    "/apis/authentication.k8s.io/v1beta1",
    "/apis/authorization.k8s.io",
    "/apis/authorization.k8s.io/v1beta1",
    "/apis/autoscaling",
    "/apis/autoscaling/v1",
    "/apis/batch",
    "/apis/batch/v1",
    "/apis/batch/v2alpha1",
    "/apis/certificates.k8s.io",
    "/apis/certificates.k8s.io/v1alpha1",
    "/apis/extensions",
    "/apis/extensions/v1beta1",
    "/apis/policy",
    "/apis/policy/v1beta1",
    "/apis/rbac.authorization.k8s.io",
    "/apis/rbac.authorization.k8s.io/v1alpha1",
    "/apis/storage.k8s.io",
    "/apis/storage.k8s.io/v1beta1",
    "/healthz",
    "/healthz/poststarthook/bootstrap-controller",
    "/healthz/poststarthook/extensions/third-party-resources",
    "/healthz/poststarthook/rbac/bootstrap-roles",
    "/logs",
    "/metrics",
    "/swaggerapi/",
    "/ui/",
    "/version"
]
}$ curl localhost:8080/api
{
"kind": "APIVersions",
"versions": [
    "v1"
],
"serverAddressByClientCIDRs": [
    {
    "clientCIDR": "0.0.0.0/0",
    "serverAddress": "10.0.2.15:8443"
    }
]
}

Конфигурация куба (вне виртуальной машины):

apiVersion: v1
clusters:
- cluster:
    certificate-authority: /home/<user>/.minikube/ca.crt
    server: https://192.168.99.104:8443
name: minikube
contexts:
- context:
    cluster: minikube
    user: minikube
name: minikube
current-context: minikube
kind: Config
preferences: {}
users:
- name: minikube
user:
    client-certificate: /home/<user>/.minikube/apiserver.crt
    client-key: /home/<user>/.minikube/apiserver.key

2

kubernetes curl kubectl minikube sles

Источник

user131120 10 мар '17 в 13:31

1 ответ

Другие вопросы по тегам kubernetes curl kubectl minikube sles

user393157 10 мар '17 в 19:35 2017-03-10 19:35 · Answer 1 · 2017-03-10 19:35

Вы сказали, что пытались curl 127.0.0.1:8080/api, но в отношении логов он пытается подключиться через https. Так что вы должны попробовать curl https://127.0.0.1:8080/api,

Я искал в исходном коде термин " Сервис недоступен", например, в описании ошибки для кода возврата HTTP 503.

Я полагаю, вы получите HTTP 503, когда вы попытаетесь curl https://127.0.0.1:8080/api,

Изменить: так как вы используете Minikube, мы можем предположить, что это работает правильно. В этом случае более вероятно, что существует проблема конфигурации. Ваши журналы говорят, что kubectl пытается подключиться к localhost, AFAIK это хост по умолчанию. Когда вы запускаете миникуб, он не запускается на хосте, а не на виртуальной машине. Следовательно localhost выглядит неправильно, и вы должны взглянуть на конфигурацию Kube.