Change:
I was successfully able to get a cluster to start up in us-west-2, the default region for kube-up, but for some reason I'm not successfully able to start up a cluster in us-east-1. I'm not seeing anything in the logs that seems to be a huge problem, so I'm not really sure how to resolve this. Kubelet log here: I'm not really sure what else to look at, I'm happy to do more investigation, but not really sure where to look. Most others log files are empty with the exception of kube- which is failing to start addons due to the unstarted api server.
cc/ Could you please help us with this?
Sure ... this sounds like a name problem - as I recall the name is supposed to be ip-172-20-0- (or similar), not just ip-172-20-0-9. I'll try in us-east-1. What revision of the software is this ?
I built from the latest master, but I have seen the same issue on recent releases.
Testing now... I wonder if this is related to and
if you entries in etcd were the fqdn of the machines then you would have been bit by the same issue as us.
I was skeptical about Running that curl returns "ip-172-20-0-9" and not "ip-172-20-0-9.ec2.internal" as we might expect?
Nvm, I tried just appending ".ec2.internal" to no avail.
I just tried it, and I was able to bring up a cluster in us-east with the latest code. I checked on my kubelet on the master, and did see your error: So I think that error is a red herring. Of course we should fix it, though I don't know if the problem is that it is missing the .ec2.internal suffix or whether the problem is that we're not registering the master as a node at all. Do you see the API server in (or ) on the master. I suspect it isn't running. Or maybe it isn't configured on your kubelet - what does show?
Nothing seems to be running:
That is odd... here is my output: Note no Note that I have arguments to kubelet (a lot of them!) The lack of arguments matches with the " No api server defined - no node status update will be sent." message in your kubelet log (which I don't have) On the "unable to resolve host ip-172-20-0-9" error, I can . It isn't in hostname, but rather I wonder if you can't ; a possible reason would be that your VPC doesn't have name resolution enabled. Did the script create it for you? Are there any hints in ? Here is mine:
VPC was created by the script and dns support and dns hostnames are both turned on. Interestingly, I'm unable to ping ip-172-20-0-9 and my is missing the search line: looks pretty close, but noticed some extra lines re: Jinja:
I think it might be the DHCP Options Set. I have another VPC in east that already had a DHCP Option Set and it appears that the kubernetes cluster is using that same set. When I looked in west I found that the set was configured as such: Whereas in east, my DHCP option set just looked like this: Perhaps we should be explicitly creating a new DHCP option set to avoid conflicts with existing VPCs? I'd be happy to create a PR if this turns out to be the issue and if you think the above is a good solution.
That is almost certainly it - nice find! I don't fully understand how this actually happened (I guess a new VPC defaults to whatever DHCP option set already exists, although that isn't what the docs say), but I would welcome a patch that created a working DHCP option set when creating a new VPC, and/or warned if a VPC had a DHCP option set which didn't include a domain-name.
Yep, cluster in us-east-1 is up and running! Thanks for all of the troubleshooting help! Another option might be to set the DHCP option set to default, which should be configured correctly. It doesn't seem like you can modify the default, so it might be a safe choice. Plus, we don't have to set up the option set, we can just assign it through the . I'll do some experimentation and make a PR with what seems to be the most sane. The documentation for option sets seems contradictory, in one place it says it will create a new option set and in another it says it will use the default. It seems it does a little bit of both. :)
should resolve once it merges.
Unfortunately this issue is still exist for me. Even tough a DHCP option is created for the Kubernetes VPC I've get an endless loop.
I figured it out, The issue was that as part of the dhcp set creation it didn't set a domain-name to be "ec2.interna" as described here - and only set the domain-server to AWS defaults. Once I changed that dhcp set it worked perfectly. I can see you a function for that issue in , it might not merged to the master? Thanks

Discussion:
fi } <ins> # Creates a new DHCP option set configured correctly for Kubernetes # Sets DHCP_OPTION_SET_ID function create-dhcp-option-set () { case "${AWS_REGION}" in us-east-1) OPTION_SET_DOMAIN=ec2.internal ;; *) OPTION_SET_DOMAIN="${AWS_REGION}.compute.internal" esac DHCP_OPTION_SET_ID=$($AWS_CMD create-dhcp-options --dhcp-configuration Key=domain-name,Values=${OPTION_SET_DOMAIN} Key=domain-name-servers,Values=AmazonProvidedDNS | json_val '["DhcpOptions"]["DhcpOptionsId"]') add-tag ${DHCP_OPTION_SET_ID} Name kubernetes-dhcp-option-set add-tag ${DHCP_OPTION_SET_ID} KubernetesCluster ${CLUSTER_ID} $AWS_CMD associate-dhcp-options --dhcp-options-id ${DHCP_OPTION_SET_ID} --vpc-id ${VPC_ID} echo "Using DHCP option set ${DHCP_OPTION_SET_ID}" } </ins> # Verify prereqs function verify-prereqs { if [[ "$(which aws)" == "" ]]; then

echo "Using VPC $VPC_ID" <ins> create-dhcp-option-set </ins> if [[ -z "${SUBNET_ID:-}" ]]; then SUBNET_ID=$($AWS_CMD describe-subnets --filters Name=tag:KubernetesCluster,Values=${CLUSTER_ID} | get_subnet_id $VPC_ID $ZONE) fi if [[ -z "$SUBNET_ID" ]]; then echo "Creating subnet." SUBNET_ID=$($AWS_CMD create-subnet --cidr-block $INTERNAL_IP_BASE.0/24 --vpc-id $VPC_ID --availability-zone ${ZONE} | json_val '["Subnet"]["SubnetId"]')