By default, GKE creates several namespaces such as kube-node-lease, kube-public, and kube-system. When creating a GKE Autopilot cluster, the default namespace is created for our workloads. GKE Standard mode allows us to specify a node pool’s newly created namespace manually.
Namespaces are used to isolate groups of resources within a single cluster. The name of the resources within a namespace must be unique but can be the same across all namespaces. Namespaces are primarily used in environments with many users, teams, or projects.
A namespace can be created with the kubectl create namespace YOUR_NAMESPACE command.
We can use the kubectl command to to view namespaces in a particular cluster.
Lastly, to delete a namespace, we need to use the kubectl delete namespaces YOUR_NAMESPACE command.
ReplicaSet
The ReplicaSet deployment type is used to maintain the desired set of Pods. It defines which image and how many Pods must be up and running.
In this sample Pod ReplicaSet deployment, we specify various information such as Pod name, labels, and how many replicas of the Pod we wish to have:
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: frontend
labels:
app: guestbook
tier: frontend
spec:
replicas: 3
selector:
matchLabels:
tier: frontend
template:
metadata:
labels:
tier: frontend
spec:
containers:
– name: php-redis
image: gcr.io/google_samples/gb-frontend:v3
The preceding code is available here: https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/controllers/frontend.yaml.
To test it out, we can deploy it using the kubectl apply -f Filename command or the preceding URL.
The preceding source code contains two important sections—the first is kind: ReplicaSet and the second is the spec section: replicas with value 3.
We can check ReplicaSets by running the kubectl get ReplicaSet command or viewing them in Cloud console.
Deployments
Deployment is the next possibility of how we can run the applications. We should use it to manage stateless applications where any Pod from the Deployment can be replaced if needed.
A Deployment provides declarative updates for Pods and ReplicaSets. It allows for a more sophisticated way to manage Pods.
We should use Deployments in the following cases:
- We want to have a rolling update where we phase out an old version of the application, and it will be replaced with a new version of the application.
- In Blue/Green deployments, where we can serve one version to a set of users, and once we are happy or unhappy with the results, it is possible to switch to the desired version of the application.
- When scaling up the deployment to accept more load.
To learn more about other deployment types, visit the Kubernetes documentation at https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#use-case.
StatefulSets
Similar to Deployments, a StatefulSet creates Pods based on the container specification. One major difference is that a StatefulSet creates and tracks the identity of each Pod. Because Pods aren’t interchangeable, the identifier will be persisted even if the Pod is rescheduled.
You might consider using StatefulSets in the following cases:
- You need to have stable and unique network identifiers.
- You require stable, persistent storage.
- Graceful and ordered deployment or scaling is needed.
- Ordered and automated rolling updates are needed.