Based on our discussion today: the easiest way to do this will be not use k8s.io/client-go and github.com/knative/serving/pkg/apis/serving/v1 package at all. With that, we need to have a KUBECONFIG file (or construct it in-memory) which complicates the configuration surface quite a bit.

If all we want to support is GKE, we can:

imitate gcloud run cli and accept --cluster-location and --cluster options
use those to get GKE cluster info (endpoint and server CA cert)
use those to construct an http client (using golang.org/x/oauth2 + /google)
make API calls to Knative API on the GKE cluster directly
the tool authenticates to the GKE master endpoint with IAM roles/container.admin role (or equivalent Kubernetes RBAC binding inside the cluster, doesn't really matter).

The only downsides I see are that:

potential data loss/corruption on ksvc object if knative serving APIs add something (even to fields like metadata:, and run/v1 package is not updated and picked up in this tool).
dealing with raw JSON and raw endpoints versus using nice client libraries (although, maybe we can actually make run/v1 work with the k8s endpoint by tweaking some options).

Support for Cloud Run for Anthos #96

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions