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.