Instead of 'value(address)' 'value(name)' should be used to make the following forwarding-rules creation command to work. With 'value(address)' it returns an error: "ERROR: (gcloud.compute.forwarding-rules.create) Could not fetch resource: - The resource 'projects/some-random-project/regions/us-central1/addresses/w.x.y.z' was not found"
there is a bug in Kubernetes 1.6.1 that causes an error when validating the kubernetes environment and etcd. (https://github.com/kubernetes/kubernetes/pull/39716) I found that using the 1.7.0 version I did not get this error. Affects the README, this file and the client configuration (moving to 1.7.0 to match)
Unless the region is explicitly passed, I get the error:
```
ERROR: (gcloud.compute.target-pools.create) Some requests did not succeed:
- Invalid value for field 'region': 'us-central1-b'. Unknown region.
```
It is cleared out at reboot.
It appears that only the file-name part of --tls-cert-file /
--tls-private-key-file is used and that the path is taken from
--cert-dir (which defaults to /var/run/kubernetes) so to make the path
stick we also add a --cert-dir
kube-controller-manager and kube-apiserver service unit files are missing
one option --cloud-provider=aws parameter, which is creating problem while
creating ELB on AWS when type: LoadBalancer is provided in service YAML file.
This commit fixes that, issue
docs/06.kubectl.md does not instruct from which node those commands must be run.
The previous modules does explain that. For a newbie its helpful to tell them
from which node they must run commands of doc/06-kubectl.md.
This PR has a minor update about that information.
This fixes issue #88 to allow pods access to PodCIDR such as the case of
DNS. When pods come up with an IP address in the cluster CIDR range,
they cannot access kubedns without a firewall rule to enable it. This
would also prevent pods from accessing each other depending on the
application.
