I've been struggling to obtain the correct hosts and (decoded) tokens from the ~/.kube/config directory on my developer machine to use this library for a few days. This has become a bigger challenge than I anticipated, as my organization uses Azure CLI with certificates to obtain these tokens for several environments via Azure Active Directory/SSO with 2FA.

Upon researching, I discovered that the official Kubernetes clients support automatically loading config files from ~/.kube/config. Here is the relevant code from their Java client, and for their JavaScript client. In particular, loadFromDetault (link) or loadFromCluster (link) seem to be the relevant functions from the JavaScript client.

The Clojure library kube-api (link) also contains an implementation in kubeconfig.clj (link) and auth.clj (link).

Another reference that might be useful is the K9s codebase (here is their config-related Go package).

Would it be interesting to have a similar feature implemented in k8s-api? This could make it easier for people with their requisite hosts and tokens in their ~/.kube/config directory to use the library with less hassle.

One possible implementation might be to use the official Kubernetes Java client to avoid porting all that code to Clojure. However, creating that dependency and using Java interop might not be desirable.

kubernetes-api.core APIs uses internals.client/find-preferred-route for finding the route to be called.

Now kubernetes-api.internals.client/find-preferred-route does

1. Search routes with find-route which only uses :kind and :action fields, this could lead to multiple match
2. Filter out Status routes (which related to #6 )
3. For multiple matched route, choose the one route for which its version is the current preferred version. If multiple such routes meets the condition, just choose the first one.

I'm encountering that two route matches all the condition:

(require '[kubernetes-api.internals.client :refer [kind action all-namespaces-route?] :as internals.client])   

(->> (internals.client/find-route k8s {:kind :Ingress
                                       :action :patch/json-merge})
     (filter (fn [x] (not (clojure.string/ends-with? (name x) "Status"))))
     (map (fn [route]
            (filter #(and (= (:name %) (internals.client/group-of k8s route))
                        (= (:version (:preferredVersion %)) (internals.client/version-of k8s route)))
                  (internals.client/all-versions k8s)))))

;; ->

(({:name "networking.internal.knative.dev",
   :versions
   [{:groupVersion "networking.internal.knative.dev/v1alpha1",
     :version "v1alpha1"}],
   :preferredVersion
   {:groupVersion "networking.internal.knative.dev/v1alpha1",
    :version "v1alpha1"}})
 ({:name "networking.k8s.io",
   :versions [{:groupVersion "networking.k8s.io/v1", :version "v1"}],
   :preferredVersion {:groupVersion "networking.k8s.io/v1", :version "v1"}}))

And it chooses "networking.internal.knative.dev" which is not what I expected and it can not be opted out (though I can hack it around thanks to with-redefs).

It would be great if route search & preferring option can be customized.

Status routes are currently explicitly disabled in kubernetes-api.internals.client/find-preferred-route. This prevents access to things like CronJobs/Status, but when I comment this out it seems to work just fine. Is there a reason for this explicit filtering out of routes ending in Status?

(defn find-preferred-route [k8s search-params]
  (->> (find-route k8s search-params)
       (filter (fn [x] (not (string/ends-with? (name x) "Status"))))
       ((partial choose-preffered-version k8s))))

Been playing with k8s-api for a while and I really like it.

However, I need watch support. Saw the docstring mentioning kubernetes/kubernetes#50857. Watch is the gateway to operators, and I am wondering how to get support in.

I also like http-kit in general but it appears to lack maintenance and it also appears to require some patching to get watch working. The next issue I encountered was lack of tls support with Java 11 in the stable version. Not super important at the moment but I'd expect graal support to be a problem as well.

Don't get me wrong: I am not saying we should be departing from http-kit immediately. I'd be fine using something else to watch for now. However, I'd also be willing to help getting support into k8s-api. ;)

Do you have any long term vision with regards to the http library/libraries to use in k8s-api?

Http ports should be allowed to be either the port number itself (integer) or a reference to a previously specified port number (string starting with a letter). Although the spec in the current schema is called int or string, the type is defaulting to a string. But passing the port number as a string is rejected by k8s api, as given a string it would expect it to start with a letter.

openapi v2 spec

curl -k https://staging-global-blue-kubernetes-api.nubank.com.br/openapi/v2 -H "Authorization: Bearer $(cat /tmp/token2)" | jq '.definitions["io.k8s.apimachinery.pkg.util.intstr.IntOrString"]'

{
  "description": "IntOrString is a type that can hold an int32 or a string.  When used in JSON or YAML marshalling and unmarshalling, it produces or consumes the inner type.  This allows you to have, for example, a JSON field that can accept a name or number.",
  "type": "string",
  "format": "int-or-string"
}

It looks like this library does non-trivial key rewriting when (de)-serializing JSON: transforming strings to keywords, kebab-case, etc.

Could we opt out of this? When it comes to API wrappers, some users (myself included) favor straightforwardness over prettiness.

So rather than write:

{:kind    :Namespace
 :action  :list
 :request {:namespace "default"
           :body      {:api-version "v1"}}}

... I would much rather write:

{:kind    :Namespace
 :action  :list
 :request {"namespace" "default"
           "body"      {"apiVersion" "v1"}}}

thus enabling more straightforward transformation between Clojure expressions and, say, JSON files passed to kubectl.