Testing on Kind: APIServer proxy not working about kpng HOT 11 CLOSED

hence the --master flag, that's the most direct way to specify an alternative target. One can also specify a HostAlias (with APIServer or a LB on port 443), inject a custom kubeconfig via a ConfigMap, etc.

from kpng.

btw it seems --master is replaced by --server nowadays, so I'll change that right now so we conform.

from kpng.

yup i changed it already :) - well hold on - we already have a --server flag, so i modified the ds.yaml to use that in my dev recipe

To solve my problem i think... KPNG server needs to tell the KPNG dataplane

"hey mister dataplane ! write apiserver routing rules on startup do this 10.0.96.1 IP !"

even before it can connect to the apiserver, right? or is this a feature request ? after all, its the service proxy's job to write host-network service APIs...

from kpng.

i guess im asking more of a theoretical question then anything else - https://groups.google.com/g/kubernetes-sig-network/c/GKwCWXlpx04

from kpng.

from kpng.

ya interesting idea

from kpng.

Solutions:

• make an apiserver client token ?
• keepalived + host-alias
• run kpng on the apiserver, --server=IP (IP is in the kube generated cert)

from kpng.

Start with kube-apiserver --token-auth-file=/srv/kubernetes/known_tokens.csv .... Set env before starting kpng KUBECONFIG=/etc/kubernetes/kubeconfig.token

The kubeconfig.token file;

apiVersion: v1
clusters:
- cluster:
    insecure-skip-tls-verify: true
    server: https://192.168.1.1:6443
  name: xcluster
contexts:
- context:
    cluster: xcluster
    user: root
  name: xcluster
current-context: xcluster
kind: Config
preferences: {}
users:
- name: root
  user:
    token: kallekula

kpng will use the $KUBECONFIG and access the api-server without problem.

from kpng.

Generate the token file;

##   kubeconfig_sec
##     Generate secure kubeconfig's
##
cmd_kubeconfig_sec() {
	local cfg=$dir/default/etc/kubernetes/kubeconfig

	export KUBECONFIG=$cfg.token
	cp $cfg $KUBECONFIG
	kubectl config set-cluster xcluster --server=https://192.168.1.1:6443
	kubectl config set-cluster xcluster --insecure-skip-tls-verify=true
	kubectl config set-credentials root --token=kallekula
}

from kpng.

My /srv/kubernetes/known_tokens.csv

kallekula,root,root
X4o3adoGo5Yx6oi4LUo2JB2GO8b0CatJ,kubelet,kubelet
tHDwA7KmaQ0jTLSKcPV2p3LrMhXP2e3m,kube_proxy,kube_proxy
cBvKaWGjXE5TnOsOW7juaO0JsXiNsxN1,system:scheduler,system:scheduler
2gxkVhMhQvMKydr7RwYYS66vXEJxy47s,system:controller_manager,system:controller_manager
isb1TVpwRYzGfshMVfTfSEDvwx2txvQt,system:logging,system:logging
JF5hfsUcDPg1JrTzlw9T6aKAQwn2BGn8,system:monitoring,system:monitoring
lXjgo4cUaiyjyCHcrn0OnonOxme6G4AV,system:dns,system:dns

from kpng.

we found a few workarounds for this:

• using the kubelet config directly and increasing its api permissions
• using the kubeconfig config similar to what kindnormally does.... and just mounting it into kubeconfig

the hack/ recipes are up to date now and working... closing... thanks for your help ulabrek and mikael ...

We have a new issue though, where somehow coredns doesnt resolve 10.96.0.1 and were not sure why yet. that is a different follow on issue though, so ill file it separately.

from kpng.