amimof / multikube Goto Github PK

following https://github.com/amimof/multikube/blob/master/docs/examples/kubernetes-example.md

kubectl create namespace multikube
kubectl create secret generic kubeconfig --from-file ~/.kube/config -n multikube
kubectl create namespace multikube
kubectl apply -f https://raw.githubusercontent.com/amimof/multikube/master/deploy/k8s.yaml

describe pod:

 Warning  FailedMount  23s (x7 over 55s)  kubelet, minikube  MountVolume.SetUp failed for volume "multikube-kubeconfig" : configmap "multikube-kubeconfig" not found

Currently the cache TTL value is hardcoded and set to 1 second. This should be a variable passed to the command line during startup. For example --cache-ttl

Many big changes since previous release and many has not yet been documented in README which contains a lot of obsolete information. Needs to be adressed before beta.1

• This feature/enhancement benefits everyone

Description
The transport cache implementation must be RFC 7234 compliant.

Additional information
N/A

x509: certificate signed by unknown authority error in Multikube log if configuring with Dex and dex is using self-signed certificates. Multikube currently isn't trusting custom ca's so we need a way of passing it in to the validator middleware.

• This feature/enhancement benefits everyone

Description
Add a flag to cmd that accepts a x509 ca certificate

Additional information
Found this issue when following the guide at dexidp/dex on how to setup Dex in Kubernetes
https://github.com/dexidp/dex/blob/master/examples/k8s/dex.yaml

Go packages needs proper testing and additionally code coverage in ci pipeline.

Target is a code coverage of >= 75%

A user must be able to get information about which clusters that multikube manages and their endpoints.
This is so that they can populate their .kube/config files.

Suggesting that we enhance proxy.go with a service that responds to /clientconfig and returns the cluster endpoints and contexts.

Eg. curl -H "Authorization: Bearer eyJh..5Q" https://127.0.0.1:8443/clientconfig

{
    "clusters": {
        "kladdis": {
            "server": "https://localhost:8443/kladdis",
            "certificate-authority-data": "xxx"
        },
        "skippy": {
            "server": "https://localhost:8443/skippy",
            "certificate-authority-data": "xxx"
        },
        "woho": {
            "server": "https://localhost:8443/woho",
            "certificate-authority-data": "xxx"
        }
    },
    "users": {
        "mk-user": {
            "token": "ey..." 
        }
    },
    "contexts": {
        "kladdis": {
            "cluster": "kladdis",
            "user": "mk-user"
        },
        "skippy": {
            "cluster": "skippy",
            "user": "mk-user"
        },
        "woho": {
            "cluster": "woho",
            "user": "mk-user"
        }
    }
}

This would have enough information for an web-frontend to display an kube/.config file that the user can download.

If the user already has an existing config file the web ui can display the commands needed to add the cluster to the configuration. Eg.

To connect to the cluster, run the following commands [copy to clipboard]

kubectl config set clusters.skippy.server https://localhost:8443/skippy
kubectl config set clusters.skippy.certificate-authority-data LS0tL...S0tLS0K
kubectl config set contexts.skippy.cluster skippy
kubectl config set contexts.skippy.user mk-user
kubectl config use-context skippy

The Transport implementation caches GET requests using the Cache interface. This means that whenever a client needs to watch a resource, for example kubectl get events -w or kubectl logs some-pod-1 -f, multikube tries to cache it. This is not a wanted behaviour.

Commit 525e555 fixes this by looking in the requested URL and bypassing the cache for requests that have either the watch=true or follow=true query params.

Even if it addresses the issue, it is not a good solution. Need to figure out a better implementation

• This feature/enhancement benefits everyone

Description
Currently the transports map is populated once a request is made. A transport is created and added to the map on the very first request to multikube. The map can be populated on proxy creation so that transports are already there once requests are served.

Additional information

Currently the Do() method of request.go will use a default empty context. The method should return a new context WithCancel() or similar so that requests are either timed-out or canceled if requested by user.