[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: OpenShift nodes switching to connect to masters via the API, not direct to etcd



Note that v0.2.1 will *NOT* have this behavior. v0.2.2 *WILL* have this behavior.

----- Original Message -----
> https://github.com/openshift/origin/pull/797 is going to change the nodes to
> connect to the master via the API, rather than through etcd.  This change
> only affects nodes, not the master or the all-in-one.  Because we're
> connecting to the master, we'll need to ensure the node has the right
> certificates to talk to the master.  If you're using the certificates
> generated by master start, you can copy the "admin" folder to the node and
> use the .kubeconfig file in that directory.
> 
> To launch a node with the right security credentials to talk to the API on
> master (over HTTPS), you do the same thing the client does:
> 
>     openshift start node --master=<address>
>     --kubeconfig=<path_to_file_with_kubeconfig>
> 
> Example of getting certs from master to node:
> 
>     # on the master
>     openshift start master
>     # generates ./openshift.local.certificates/admin/.kubeconfig, key.key,
>     cert.rct, and root.crt
> 
>     tar -czf certs.tar.gz -C ./openshift.local.certificates/admin .
>     # tar up those certs
> 
>     # on the node
>     tar -xvzf certs.tar.gz -C ./some/directory
>     
>     openshift start node --master=<masteraddress>
>     --kubeconfig=./some/directory/.kubeconfig
> 
> We are *not* enabling HTTPS on the Kubelet at this time (still HTTP).  You
> should limit access to the kubelets from outside your cluster.  When we do,
> there will be some directory created by the master like "admin" but with a
> set of credentials for the kubelet talking to the master, AND credentials
> for the master to talk to the kubelet, AND a server cert for the kubelet to
> listen on.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]