liveBook · Manning

Namespace

As explained in Google Anthos in Action

A namespace is a Kubernetes logical partition that scopes and organizes namespaced resources within a cluster.

A namespace is a logical partition of a Kubernetes cluster. Resource names must be unique within a namespace, but the same name can be used in another. A namespaced resource is managed at namespace rather than cluster scope. Namespaces help organize shared clusters for multiple tenants; services also receive DNS names that include their namespace. section 3.2.6

A namespace provides a place to apply controls, not a complete tenant-safety configuration by itself. Use RBAC, resource quotas, network policies, and namespace security resources where the workload requires them. For codependent Pods in a migrated multi-VM stack, placing them in one namespace permits short DNS names; NetworkPolicy can restrict access between frontend and backend Pods. section 3.2.6 section 15.5

Prepare an application namespace for service-mesh injection

After installing Anthos Service Mesh, check its control-plane Pods with `kubectl get pods -n istio-system`. Create the application namespace with `kubectl create namespace demo`, then inspect the `istio.io/rev` value on istiod Pods using `kubectl -n istio-system get pods -l app=istiod --show-labels`. Label the new namespace with the version found in that cluster; the example uses `kubectl label namespace demo istio.io/rev=asm-1124-2`. Deploy the application into `demo` with `kubectl apply -n demo -f online-boutique`. The revision value is cluster-specific, not a value to copy blindly. section 4.7.1

Deployment tooling also uses namespaces as targets. In Cloud Marketplace, a GKE deployment can select a cluster and namespace. On Anthos GKE on-prem, Marketplace deployment requires additional preparation: create an `application-system` namespace if needed, configure an image-pull Secret, and create and annotate each target namespace with its Secret. Check registry connectivity and, when Istio blocks external connections, configure the required egress before deployment. section 14.1.3 section 14.2.1

JSON_KEY_FILENAME=path_to/service_account_key.json
IMAGEPULLSECRET_NAME=gcr-json-key
kubectl create secret docker-registry $IMAGEPULLSECRET_NAME \
 --namespace=$NAMESPACE_NAME \
 --docker-server=gcr.io \
 --docker-username=_json_key \
 --docker-password="$(cat ~/$JSON_KEY_FILENAME)"

kubectl annotate namespace $NAMESPACE_NAME marketplace.cloud.google.com/imagePullSecret=$IMAGEPULLSECRET_NAME

The listing shows the per-target-namespace image-pull Secret and annotation used for an on-prem Marketplace deployment; replace the namespace and key-file placeholders. section 14.1.3

How Google Anthos in Action covers it

How deep it goes
Defines namespace scope and works through creation, labeling, and deployment preparation; defers details of individual security controls.
Examples
Uses a service-mesh application namespace, an on-prem Marketplace target namespace, and a GKE Elasticsearch deployment choice.
What it assumes
Assumes cluster access and, for on-prem Marketplace preparation, cluster-admin credentials; shows namespace creation commands explicitly.
What you can do after
Operate/configure it with kubectl to create and label a namespace, then target it for application deployment.
How it connects
Connects namespaces to RBAC, resource quotas, NetworkPolicy, service DNS, sidecar injection, and image-pull Secrets.

Also explained in

Compare how 20 books explain namespace →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Google Anthos in Action. The section links point to the parts of the book it draws on.