Kops: kops installation on aws ::::: kubectl command not working after installing and creating cluster

Created on 24 Jan 2017  路  19Comments  路  Source: kubernetes/kops

root@ip-172-31-46-246:/usr/local/bin# kubectl get nodes
Unable to connect to the server: dial tcp: lookup api.uswest2.kuber.shi.com on 172.31.0.2:53: no such host

I have followed 100% correct documentation to install kops.
https://kubernetes.io/docs/getting-started-guides/kops/

I have used this command for ROute53
aws route53 create-hosted-zone --name kuber.shi.com --caller-reference 3

S3
aws s3 mb s3://clusters.kuber.shi.com

Cluster get created I can also see created cluster in AWS dashboard

When I try below command :+1:

root@ip-172-31-46-246:/usr/local/bin# kubectl get nods
Unable to connect to the server: dial tcp: lookup api.uswest2.kuber.shi.com on 172.31.0.2:53: no such host

When i connect to Master through SSH -i
and do following command I get
admin@ip-172-20-41-222:/usr/local/bin$ kubectl get no
The connection to the server localhost:8080 was refused - did you specify the right host or port?

All 19 comments

We have some additional docs in review that may be clearer.

Can you check in particular this one: https://github.com/kubernetes/kops/pull/1538/files#diff-5803986eae4dd3a69a265d54997b0040

It sounds as if your NS records are not set up.

Another possibility: if you are using a private hostedzone, you may need to attach that HostedZone to your VPC. We should do this automatically for you in kops 1.5.0-alpha4 if you specify --dns private though.

Which version of kops is this (kops version)0?

Hi justinsb ,

Thanks for reply...

I dont have real domain , can u please suggest me what to do in that case.

I have v1.4.0 kops version.

If need i can try 1.5-alpha also.

Please suggest.

You need a domain. We have had some thoughts about using instance names and such, but currently you need a real domain.

So is there any other way to create kubernetes clusterin AWS ?
Please suggest.

There are. Can you swing by sig-aws?

I'm experiencing a similar issue. I'm using a Route 53 private hosted zone associated with a VPC where both DNS resolution and hostname are enabled. The first thing that I noticed was odd was that after running kops create cluster successfully, the A name record for the master k8s node was incorrect so I had to manually change the IP address to the correct one that appeared in the EC2 dashboard for that node. That got my DNS resolving correctly after the newly updated A record propagated.

The next issue I found was that I could not run any kubectl commands from my client to the k8s master node, more specifically the node addressed by api.k8s.isyslabs.net. I kept getting connection refused messages like this:

$ kubectl get nodes
The connection to the server api.k8s.isyslabs.net was refused - did you specify the right host or port?

I knew I had the right host because I could telnet and ssh to the server on port 22. So maybe I had the port incorrect. It seemed that by default kubectl wanted to connect on port 443. I checked my Security Groups and all the inbound entries were correct. However, two observations:

$ telnet api.k8s.isyslabs.net 22
Trying VV.XX.YY.ZZ...
Connected to api.k8s.isyslabs.net.
Escape character is '^]'.
SSH-2.0-OpenSSH_6.7p1 Debian-5+deb8u3
$ telnet api.k8s.isyslabs.net 443
Trying VV.XX.YY.ZZ...



md5-55719b936880a6b620cc311c94441800



$ netstat -tln
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State      
tcp        0      0 127.0.0.1:10248         0.0.0.0:*               LISTEN     
tcp        0      0 127.0.0.1:10249         0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:39856           0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN     
tcp6       0      0 :::4194                 :::*                    LISTEN     
tcp6       0      0 :::10250                :::*                    LISTEN     
tcp6       0      0 :::10251                :::*                    LISTEN     
tcp6       0      0 :::10252                :::*                    LISTEN     
tcp6       0      0 :::45005                :::*                    LISTEN     
tcp6       0      0 :::10255                :::*                    LISTEN     
tcp6       0      0 :::111                  :::*                    LISTEN  



md5-07183338078e8e6d305ec4d91ba6d455



$ ps ax | grep kub
 1222 ?        Ssl    0:00 /usr/bin/docker run -v /:/rootfs/ -v /var/run/dbus:/var/run/dbus -v /run/systemd:/run/systemd --net=host --privileged protokube:1.5.3 /usr/bin/protokube --channels=s3://natemurthy-artifacts/kops-state/k8s.isyslabs.net/addons/bootstrap-channel.yaml --cloud=aws --containerized=true --dns-internal-suffix=.internal.k8s.isyslabs.net --dns=aws-route53 --master=true --v=4 --zone=k8s.isyslabs.net
 1246 ?        Ssl    0:00 /usr/bin/protokube --channels=s3://natemurthy-artifacts/kops-state/k8s.isyslabs.net/addons/bootstrap-channel.yaml --cloud=aws --containerized=true --dns-internal-suffix=.internal.k8s.isyslabs.net --dns=aws-route53 --master=true --v=4 --zone=k8s.isyslabs.net
 1293 ?        Ssl    0:20 /usr/local/bin/kubelet --allow-privileged=true --api-servers=http://127.0.0.1:8080 --babysit-daemons=true --cgroup-root=docker --cloud-provider=aws --cluster-dns=100.64.0.10 --cluster-domain=cluster.local --enable-debugging-handlers=true --eviction-hard=memory.available<100Mi,nodefs.available<10%,nodefs.inodesFree<5%,imagefs.available<10%,imagefs.inodesFree<5% --hostname-override=ip-172-20-53-185.us-west-2.compute.internal --network-plugin=kubenet --node-labels=kubernetes.io/role=master --non-masquerade-cidr=100.64.0.0/10 --pod-manifest-path=/etc/kubernetes/manifests --register-schedulable=false --v=2
 1568 ?        Ss     0:00 /bin/sh -c echo -998 > /proc/$$/oom_score_adj && kube-proxy --kubeconfig=/var/lib/kube-proxy/kubeconfig --resource-container="" --master=http://127.0.0.1:8080 --v=2 1>>/var/log/kube-proxy.log 2>&1
 1578 ?        Sl     0:01 kube-proxy --kubeconfig=/var/lib/kube-proxy/kubeconfig --resource-container= --master=http://127.0.0.1:8080 --v=2
 1621 ?        Ss     0:00 /bin/sh -c /usr/local/bin/kube-scheduler --leader-elect=true --master=127.0.0.1:8080 --v=2 1>>/var/log/kube-scheduler.log 2>&1
 1633 ?        Sl     0:04 /usr/local/bin/kube-scheduler --leader-elect=true --master=127.0.0.1:8080 --v=2
 1809 ?        Ss     0:00 /bin/sh -c /usr/local/bin/kube-controller-manager --allocate-node-cidrs=true --attach-detach-reconcile-sync-period=1m0s --cloud-provider=aws --cluster-cidr=100.96.0.0/11 --cluster-name=k8s.isyslabs.net --configure-cloud-routes=true --leader-elect=true --master=127.0.0.1:8080 --root-ca-file=/srv/kubernetes/ca.crt --service-account-private-key-file=/srv/kubernetes/server.key --v=2 1>>/var/log/kube-controller-manager.log 2>&1
 1819 ?        Sl     0:00 /usr/local/bin/kube-controller-manager --allocate-node-cidrs=true --attach-detach-reconcile-sync-period=1m0s --cloud-provider=aws --cluster-cidr=100.96.0.0/11 --cluster-name=k8s.isyslabs.net --configure-cloud-routes=true --leader-elect=true --master=127.0.0.1:8080 --root-ca-file=/srv/kubernetes/ca.crt --service-account-private-key-file=/srv/kubernetes/server.key --v=2



md5-b8b703dab48134f93b4fbbdc4da63127



$ telnet localhost 8080
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused

and no surprises.

So what's the deal?

I'm having the same issues. I've double checked the R53 recordset matches the entries I added to my domain.

The nodes show up in EC2 (per my config), but there's no master.

In my case, It seems that although "us-east-1a" shows up for aws ec2 describe-availability-zones --region us-east-1, it doesn't actually work. "us-east-1d" did. I don't understand why.

Same issue

kops 1.6.0-beta1
k8s 1.6.2 & 1.5.4

Protokube logs loop in:

I0509 09:47:35.558077       1 channels.go:50] apply channel output was: Error: error querying kubernetes version: Get https://127.0.0.1/version: dial tcp 127.0.0.1:443: getsockopt: connection refused
Usage:
  channels apply channel [flags]

Flags:
  -f, --filename stringSlice   Apply from a local file
      --yes                    Apply update

Global Flags:
      --alsologtostderr                  log to standard error as well as files
      --config string                    config file (default is $HOME/.channels.yaml)
      --log_backtrace_at traceLocation   when logging hits line file:N, emit a stack trace (default :0)
      --log_dir string                   If non-empty, write log files in this directory
      --logtostderr                      log to standard error instead of files (default false)
      --stderrthreshold severity         logs at or above this threshold go to stderr (default 2)
  -v, --v Level                          log level for V logs (default 0)
      --vmodule moduleSpec               comma-separated list of pattern=N settings for file-filtered logging


error querying kubernetes version: Get https://127.0.0.1/version: dial tcp 127.0.0.1:443: getsockopt: connection refused
W0509 09:47:35.558136       1 kube_boot.go:145] error applying channel "s3://kubernetes-staging-kubernetes-state-store/kubernetes.staging.porntube.com/addons/bootstrap-channel.yaml": error running channels: exit status 1

I had exactly the same issue @richburdon reported in his comment: starting the cluster in us-east-1a doesn't seem to work (I get an error message saying cannot get nodes when issuing kops validate cluster) but starting the cluster in us-east-1d with the same configuration works like a charm. Both availability zones show up when issuing aws ec2 describe-availability-zones --region us-east-1.

Do you have m3 instance types in us-east-1a? Change the master instance type to a m4 in us-east-1a

Yes, I had m3 instances types in us-east-1a for master and changing it to m4 works, thanks a lot.

Closing ;)

@natemurthy have you resolved your issue if so I would like to know how you did that. I am still facing the same issue. I am performing kops validate cluster but ending up with connection refused error. It is the same with "kubectl get nodes".
The connection to the server api.xxxxx.xxxx.xxx was refused - did you specify the right host or port?
@chrislovecnm any suggestions please?

I've upgraded to kops 1.6.1, and I'm still experiencing this issue.

@chrislovecnm Can we please re-open?

This time I used m4.large instances, and got a bit further. I noticed that kops will create 4 additional A records in my hosted zone for the names:

api.sub.domain.com
api.internal.sub.domain.com
etcd-b.internal.sub.domain.com
etcd-events-b.internal.sub.domain

However, the IP addresses assigned to these records all appear to be bogus. There are no VMs that have these IP addresses. I did however change the IP address of api.sub.domain.com to the IP address of the master. This got me as far as being able view just the master node, but none of the worker nodes show up (even though the EC2 dashboard shows they are running):

$ kubectl get nodes
NAME                                          STATUS         AGE       VERSION
ip-xxx-xx-xx-xxx.us-west-2.compute.internal   Ready,master   9m        v1.6.2

So I've made a bit of progress, but it still appears that I have more manual work (not exactly sure what though) to do to get this fully working. What should the IP address of the other names be set to? I've tried setting them to both the private and public IP addresses, neither of those values worked -- still couldn't view any of the kubelet nodes.

Cross-linking with previously reported DNS-related issue https://github.com/kubernetes/kops/issues/1386

I have found a solution at least for my issue. The actual problem is, I was using a private image from our corporate due to the way it was developed it has some issues when installed and running kops ( I was unable to ssh and ping the private IP at least of the master node running in aws). Later I have changed the image to a public one (ubuntu) and began the entire process again debugging the issue.
`kops create cluster

--cloud=aws
--zones=eu-central-1a
--node-size=t2.small
--master-size=t2.small
--node-count=2
--name=gave a name here
--dns-zone=my DNS name
--dns private
--vpc=vpc-xxxxxx
--network-cidr=172.xx.xx.xx/xx
--state=s3://waterinthebucket
--image ami-xxxxx
--ssh-public-key=~/keys/id_rsa.pub`
I have launched the cluster with above configuration but I still had the issue. When I looked into my aws account I found that the above script is creating a new route table for an existing VPC. I have an existing route table previously for that VPC with defined rules but the new one flushed all of them and have only two rules in that. So I've manually changed my route table configurations and also changed the PlaceholdereIP=203.0.113.123 of all 4 sub domains (api,api,etcd,etcd) under hosted zones to my private Ip address of the master node and waited for 5 mins for DNS to reconfigure. Now everything works perfectly. @natemurthy thanks for bringing #1386 it has set a correct path.
edit: here they have mentioned about the creation of shred subnets https://github.com/kubernetes/kops/blob/master/docs/run_in_existing_vpc.md#running-in-a-shared-subnet

Aha! I needed to set the --dns=private flag and that got things working with my Route53 setup.

Was this page helpful?
0 / 5 - 0 ratings