implement more bindings to the standard api-resources

[clux]

We got core::v1 covered AFAIKT. But a quick peek at the openapi spec shows there's still tons of uncovered resources.

As a starting point, let's aim to cover the normal kubectl api-resources output:

NAME                              SHORTNAMES   APIGROUP                             NAMESPACED   KIND
bindings                                                                            true         Binding
componentstatuses                 cs                                                false        ComponentStatus
configmaps                        cm                                                true         ConfigMap
endpoints                         ep                                                true         Endpoints
events                            ev                                                true         Event
limitranges                       limits                                            true         LimitRange
namespaces                        ns                                                false        Namespace
nodes                             no                                                false        Node
persistentvolumeclaims            pvc                                               true         PersistentVolumeClaim
persistentvolumes                 pv                                                false        PersistentVolume
pods                              po                                                true         Pod
podtemplates                                                                        true         PodTemplate
replicationcontrollers            rc                                                true         ReplicationController
resourcequotas                    quota                                             true         ResourceQuota
secrets                                                                             true         Secret
serviceaccounts                   sa                                                true         ServiceAccount
services                          svc                                               true         Service
mutatingwebhookconfigurations                  admissionregistration.k8s.io         false        MutatingWebhookConfiguration
validatingwebhookconfigurations                admissionregistration.k8s.io         false        ValidatingWebhookConfiguration
customresourcedefinitions         crd,crds     apiextensions.k8s.io                 false        CustomResourceDefinition
apiservices                                    apiregistration.k8s.io               false        APIService
controllerrevisions                            apps                                 true         ControllerRevision
daemonsets                        ds           apps                                 true         DaemonSet
deployments                       deploy       apps                                 true         Deployment
replicasets                       rs           apps                                 true         ReplicaSet
statefulsets                      sts          apps                                 true         StatefulSet
tokenreviews                                   authentication.k8s.io                false        TokenReview
localsubjectaccessreviews                      authorization.k8s.io                 true         LocalSubjectAccessReview
selfsubjectaccessreviews                       authorization.k8s.io                 false        SelfSubjectAccessReview
selfsubjectrulesreviews                        authorization.k8s.io                 false        SelfSubjectRulesReview
subjectaccessreviews                           authorization.k8s.io                 false        SubjectAccessReview
horizontalpodautoscalers          hpa          autoscaling                          true         HorizontalPodAutoscaler
cronjobs                          cj           batch                                true         CronJob
jobs                                           batch                                true         Job
certificatesigningrequests        csr          certificates.k8s.io                  false        CertificateSigningRequest
leases                                         coordination.k8s.io                  true         Lease
events                            ev           events.k8s.io                        true         Event
ingresses                         ing          extensions                           true         Ingress
nodes                                          metrics.k8s.io                       false        NodeMetrics
pods                                           metrics.k8s.io                       true         PodMetrics
networkpolicies                   netpol       networking.k8s.io                    true         NetworkPolicy
poddisruptionbudgets              pdb          policy                               true         PodDisruptionBudget
podsecuritypolicies               psp          policy                               false        PodSecurityPolicy
clusterrolebindings                            rbac.authorization.k8s.io            false        ClusterRoleBinding
clusterroles                                   rbac.authorization.k8s.io            false        ClusterRole
rolebindings                                   rbac.authorization.k8s.io            true         RoleBinding
roles                                          rbac.authorization.k8s.io            true         Role
priorityclasses                   pc           scheduling.k8s.io                    false        PriorityClass
storageclasses                    sc           storage.k8s.io                       false        StorageClass
volumeattachments                              storage.k8s.io                       false        VolumeAttachment

That's what a 1.13 cluster supports (but took out some extensions == v1beta versions of workloads api).

There's many ways of finding the Api values for a resource. One way is to browse to the openapi spec for a resource - here Service as an example. Then view src on the first create request which should easily show a __url of the form:

let __url = format!("/api/v1/namespaces/{namespace}/services?", namespace = namespace);

In this case we can infer the resource is:

RawApi {
    resource: "services".into(),
    group: "".into(),
    ..Default::default()
}

(note the v1 version + apis prefix and unset namespace defaults).

It would need a v1Service constructor in RawApi.

It would also need the following entry for the "openapi" users:

use k8s_openapi::api::core::v1::{ServiceSpec, ServiceStatus};
impl Api<Object<ServiceSpec, ServiceStatus>> {
    pub fn v1Service(client: APIClient) -> Self {
        Api {
            api: RawApi::v1Service(),
            client,
            phantom: PhantomData,
        }
    }
}

[clux]

Note that not all objects fit the Object<P, U> model: so the impl Api<ServiceAccount> (say) needs to define the struct itself and then impl KubeObject on it. See snowflake.rs for how to do this.

Resources that definitely are snowflakes:

• RoleBinding with subjects + roleRef
• Role with a rules vec
• ConfigMap - with data + binaryData
• Endpoints - with a subsets vector
• Event - with 17 random fields!
• ServiceAccount - secrets vector + misc fields

#35 for context. https://kubernetes.io/docs/reference/federation/v1/definitions/ for actual api of what's required. Likely necessary to look at when implementing these.

[LukeMathWalker]

I'd like to take a stub at Namespace and Hpa, given that I have been using them recently 😁

[clux]

This is somewhat less of a hassle now that we only need two lines in the api module:

k8s_obj!("Service", "v1", "api");
k8s_ctor!(Service, "v1", k8s_openapi::api::core);

Though it would be nice to have a way to automatically detect the objects from k8s api / openapi crate so that we could generate the ones that existed.

Perhaps it is possible to expose the ctor macro so that openapi was less tied to this crate, but doubt that is possible because it needs to do an impl on Api which is owned by this crate.

If we can generate a declarative format for all the native api types, then we could possibly even build kube with just the objects needed with a build script evar - though that's probably unnecessarily over-engineered. Still, being able to define all types easily from an upstream spec in a format we can derive would be super helpful.

[clux]

Potentially even easier on nightly with const generics:

struct Attacher<const N: usize> {}
impl<const N: usize> Attacher<N> {
    const fn attach(values: [&str; N]) -> () {
        k8s_obj!(c, "v1", "", "api");
        k8s_ctor!(c, "v1", k8s_openapi::api::core);
    }
}
const CORE_OBJS: [&str; 8] = ["Pod", "Node", "Service", "Namespace", "PersistentVolume", "ResourceQuota", "PersistentVolumeClaim", "ReplicationController"];
static Y: [(); 8] = Attacher::<8>::attach(CORE_OBJS);

[clux]

Going to allow arbitrary k8s_openapi objects to work thanks to trait in the upstream crate. This will be fixed in #157

[clux]

No longer necessary from next version since we can use any k8s_openapi type that uses ObjectMeta herein.