Kubernetes has several nested layers, each of which provides some level of isolation and security. Building on the container, Kubernetes layers provide progressively stronger isolation. Here are the layers of a Kubernetes environment:

๐๐๐จ๐ง๐ญ๐๐ข๐ง๐๐ซ (๐ง๐จ๐ญ ๐ฌ๐ฉ๐๐๐ข๐๐ข๐ ๐ญ๐จ ๐๐ฎ๐๐๐ซ๐ง๐๐ญ๐๐ฌ):
๐A container provides basic management of resources, but does not isolate identity or the network. It provides some security isolation, but only provides a single layer, compared to our desired double layer.
๐๐๐จ๐:
๐A pod isolates a few more resources than a container, including the network. It does micro-segmentation using Kubernetes Network Policy, which dictates which pods can speak to one another. But it still suffers from noisy neighbors on the same host.
๐๐๐จ๐๐:
๐A node includes a collection of pods, and has a superset of the privileges of those pods. A node leverages a hypervisor or hardware for isolation, including for its resources.
You can use firewall rules to restrict network traffic to the node.
๐๐๐ฅ๐ฎ๐ฌ๐ญ๐๐ซ:
๐A cluster is a collection of nodes and a control plane. This is a management layer for your containers. Clusters offer stronger network isolation with per-cluster DNS.
๐๐๐ซ๐จ๐ฃ๐๐๐ญ:
๐A GCP project is a collection of resources, including Kubernetes Engine clusters. A project provides all of the above, plus some additional controls that are GCP-specific, like project-level IAM for Kubernetes Engine and org policies. Resource names, and other resource metadata, are visible up to this layer.
Thereโs also the ๐๐ฎ๐๐๐ซ๐ง๐๐ญ๐๐ฌ ๐๐๐ฆ๐๐ฌ๐ฉ๐๐๐, the fundamental unit for authorization in Kubernetes. A namespace can contain multiple pods. Namespaces provide some control in terms of authorization, via namespace-level RBAC, but donโt try to control resource quota, network, or policies.