On Thu, Feb 9, 2017 at 6:39 AM, Jeremy Derr <jer...@derr.me> wrote:
> the federation pods start and stay running. the connection to the
> federated clusters never succeeds, instead throwing the TLS errors I quote.
>
The component that connects to federated clusters is the federation
controller manager. But it looks like the log snippet above is for the API
server. So it looks like there are two separate problems.
Check your controller manager logs. Also, verify that the credentials used
by the federation controller manager (`kubectl
--namespace=federation-system get secret troopers-controller-manager-kubeconfig
--template '{{.data.kubeconfig}}' | base64 -d`) to talk to the federation
API server is recognized by the API server (exec into the pod and look for
the certs and keys in /etc/federation/apiserver/).
It is really hard to say what's going in without additional context (more
logs, see inlined questions in the previous email).
> the net result is that if I submit an object (say, a namespace) to the
> federated control plane, it never propagates to the federated clusters.
>
> On Thu, Feb 9, 2017 at 3:10 AM 'Madhusudan C.S.' via Kubernetes user
> discussion and Q&A <kubernetes-users@googlegroups.com> wrote:
>
>>
>>
>> On Wednesday, February 8, 2017 at 10:48:13 AM UTC-8, Jeremy Derr wrote:
>>
>> I have a utility cluster ("cloudops"), created with kops, that I use for
>> a bunch of non-customer facing, DevOps-y workloads. I decided to give
>> Federation a shot for my customer-facing clusters.
>>
>> So, I created two kubernetes clusters ("appo" and "cody") in AWS with
>> `kops` with the following commands:
>>
>> kops create cluster --name cody.us-east-1e.derr.me --zones
>> us-east-1e --vpc vpc-7a3c5d1d --dns-zone us-east-1e.derr.me
>> --network-cidr 10.10.0.0/16 --topology private --networking calico
>> --ssh-public-key ~/.ssh/id_rsa.pub
>> kops create cluster --name appo.us-east-1e.derr.me --zones
>> us-east-1e --vpc vpc-7a3c5d1d --dns-zone us-east-1e.derr.me
>> --network-cidr 10.10.0.0/16 --topology private --networking calico
>> --ssh-public-key ~/.ssh/id_rsa.pub
>>
>> The only change I made with `kops edit` was to ensure they had AWS VPC
>> subnets that do not conflict with one another.
>>
>> I then started a federated control plane:
>>
>> kubefed init troopers --host-cluster-context=cloudop
>> s.us-east-1e.derr.me --dns-provider=aws-route53 --dns-zone-name=
>> fed.derr.me
>>
>> and then added these two clusters to this federated control plane:
>>
>> kubefed join cody --host-cluster-context=troopers --cluster-context=
>> cody.us-east-1d.derr.me
>> kubefed join appo --host-cluster-context=troopers --cluster-context=
>> appo.us-east-1e.derr.me
>>
>> From this point, the federated API server will just throw endless TLS
>> errors and federation never begins.
>>
>>
>> By "never begins", do you mean the pods keep crashing? Do the pods
>> restart? What does `kubectl --namespace=federation-system describe pods`
>> return?
>>
>> I0208 16:32:40.007161 1 logs.go:41] http: TLS handshake error
>> from 10.10.55.2:37510: EOF
>> I0208 16:32:40.007730 1 logs.go:41] http: TLS handshake error
>> from 100.78.245.128:48267: EOF
>> I0208 16:32:40.007944 1 logs.go:41] http: TLS handshake error
>> from 100.123.106.0:53971: EOF
>> I0208 16:32:40.008085 1 logs.go:41] http: TLS handshake error
>> from 100.76.57.192:58049: EOF
>> I0208 16:32:40.008224 1 logs.go:41] http: TLS handshake error
>> from 100.110.103.8:21103: EOF
>> I0208 16:32:40.008362 1 logs.go:41] http: TLS handshake error
>> from 100.97.177.64:53690: EOF
>> I0208 16:32:40.008621 1 logs.go:41] http: TLS handshake error
>> from 100.120.95.192:58706: EOF
>>
>>
>> Any idea what these addresses are? Could you give more context (more
>> logs)?
>>
>> Also, do you see `https://` prefix in the endpoint addresses in the
>> cluster objects when you run `kubectl --context=troopers get clusters cody
>> -o yaml` and `kubectl --context=troopers get clusters appo -o yaml`?
>>
>>
>>
>> What am I missing here?
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Kubernetes user discussion and Q&A" group.
>> To unsubscribe from this topic, visit https://groups.google.com/d/to
>> pic/kubernetes-users/LGmHHcvxvAQ/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> kubernetes-users+unsubscr...@googlegroups.com.
>> To post to this group, send email to kubernetes-users@googlegroups.com.
>> Visit this group at https://groups.google.com/group/kubernetes-users.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> Jeremy Derr
> jer...@derr.me
>
> When in trouble or in doubt, run in circles, scream and shout.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Kubernetes user discussion and Q&A" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/to
> pic/kubernetes-users/LGmHHcvxvAQ/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> kubernetes-users+unsubscr...@googlegroups.com.
> To post to this group, send email to kubernetes-users@googlegroups.com.
> Visit this group at https://groups.google.com/group/kubernetes-users.
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"Kubernetes user discussion and Q&A" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to kubernetes-users+unsubscr...@googlegroups.com.
To post to this group, send email to kubernetes-users@googlegroups.com.
Visit this group at https://groups.google.com/group/kubernetes-users.
For more options, visit https://groups.google.com/d/optout.
