0

(I'm not sure if this is a common requirement, or I'm asking for a hack, but I will try anyway)

We deploy different project for every developer on Google Kubernetes Engine, all under the same billing account. For example, my development project is kp-dev-project, whereas, one of my team members has xyz-dev-project. We also have a "common" project that we use for integration deployments, called intg-project.

We have created two resources under the intg-project:

  1. A container registry (gcr.io/intg-project), where our CI pipeline pushes the images; for example grc.io/intg-project/hello:1.0
  2. A managed zone under the Google Cloud DNS called dev.example.com

Here's the question:

Is there a way in GKE to refer to the resources created in the "common" project from other projects? For example, when I'm developing, I have my gcloud configuration set to my own profile called kp-dev-profile. If I try to deploy a Kube spec that refers to an image from the grc.io/intg-project/hello:1.0, I get an error as shown below:

Failed to pull image "gcr.io/intg-project/hello:1.0": rpc error: code = Unknown desc = Error response from daemon: repository gcr.io/intg-project/hello not found: does not exist or no pull access

Similarly, if I try to list all managed zones using gcloud dns managed-zones list, I do not see the managed zone dev.example.com.

As soon as I change my profile to intg-profile, or set the project in my kp-dev-profile profile as intg-project, I can access both resources. Note:, my user in Google IAM has the necessary permissions (In fact, I'm actually an "Owner" for the intg-project)

It kinda makes sense: Google creates each "project" as an isolated sandbox for resources, and does not expose any resource outside of the project.

But then perhaps, it does not make sense: A "project" sounds very much like a sandboxing mechanism for me to keep the work of my developers independent an isolated, while still wanting to leverage a common managed zone and a common container registry.

Any thoughts?

UPDATE

I was able to configure the Google Container Registry as an "external" private Docker registry using the GCP Service Account key and a Docker Secret. All credits to this article on Heptio.com.

Kartik Pandya
  • 2,718
  • 2
  • 14
  • 28

1 Answers1

0

The dedicated CI / CD cloud project builds, pushes, tests Docker images and deploys continuously new versions of images on each Google Kubernetes Engine environment.

Those environments are provisioned under separate projects such as development, staging, and production.

What do you mean by a commonly managed zone? Can you give me more details?

Yes, you can leverage a common container registry.

You can Grant pull access to another project See the attached link [1] for more details,

[1]https://googlecloud.tips/tips/029-cross-project-container-registry/

You can also check this document [2] on setting up Clusters with Shared VPC. You designate one project as the host project, and you can attach other projects, called service projects, to the host project. You can use Shared VPC with both zonal and regional clusters.

[2]https://cloud.google.com/kubernetes-engine/docs/how-to/cluster-shared-vpc

You can also specify the --project parameter for a command to operate against a different project for that invocation.

Moreover, you can Grant users and other projects access to a registry, see the link[3] for more details

[3]https://cloud.google.com/container-registry/docs/access-control#granting_users_and_other_projects_access_to_a_registry

Muhammad Ebaduddin
  • 124
  • 2