Supplement to Kubernetes Concepts
In addition to the basic concepts discussed in part one, there are some additional concepts that are still worth understanding.
Namespace
A namespace in Kubernetes is a logical space used to isolate different resources. Through namespaces, resources can be divided into different groups to achieve resource isolation and management.
ConfigMap and Secret
ConfigMap
ConfigMap is an API object used to store non-sensitive data in key-value pairs. When used, a Pod can use it as environment variables, command-line parameters, or configuration files in volumes.
ConfigMap decouples your environment configuration from your container image, making it easier to modify application configurations.
ConfigMap does not provide confidentiality or encryption features. If you need to store sensitive data, use Secret or other third-party tools to ensure the confidentiality of your data, rather than ConfigMap.
Use ConfigMap to separate your configuration data from your application code.
Secret
Secret is an object that contains a small amount of sensitive information such as passwords, tokens, or keys. Such information may be included in the specification of a Pod or in an image. Using Secret means you don’t need to include sensitive data in your application code.
Because creating Secret can be done independently of Pods that use them, there is less risk of exposing Secrets (and their data) in workflows for creating, viewing, and editing Pods. Kubernetes and applications running in the cluster can also take additional precautions with Secrets, such as avoiding writing sensitive data to non-volatile storage.
Secrets are similar to ConfigMap but are specifically used to store sensitive data.
Secrets can be used in the following scenarios:
- Setting environment variables for containers.
- Providing credentials such as SSH keys or passwords to Pods.
- Allowing kubelet to pull images from private image repositories.
Kubernetes control planes also use Secrets; for example, bootstrap token Secrets are a mechanism to help automate node registration.
Volume
Volume is a mechanism in Kubernetes used to persist data.
Files in containers are temporarily stored on disk, which poses some challenges for running critical applications in containers. When a container crashes or stops, a problem arises. At this point, the container state is not saved, so all files created or modified during the container’s lifecycle are lost. During a crash, kubelet restarts the container in a clean state. Another problem arises when multiple containers run in a Pod and need to share files. It is challenging to set up and access a shared file system across all containers.
StatefulSet
StatefulSet and Deployment in Kubernetes are both objects used to manage application replicas, but they have some important differences:
- Stable Identifiers:
- In Deployment, each replica is interchangeable, with no specific identifier between them. This means that if one replica fails, it can be replaced by any new replica, and the new replica may have a different IP address or hostname.
- In StatefulSet, each replica has a stable identifier, usually named with an ordered numerical sequence, such as
pod-0,pod-1,pod-2, etc. This means that each replica will maintain the same identifier throughout its lifecycle, without changing with restarts or replacements.
- Persistent Storage:
- StatefulSet is designed for applications that require persistent storage, such as databases. It supports assigning persistent volumes to each replica, ensuring that data remains unchanged even if replicas are restarted or replaced.
- Deployment is typically used for stateless applications that do not require persistent storage, where replicas can be replaced without affecting the application’s state.
- Pod Ordering and Management:
- In StatefulSet, the creation, deletion, and updating order of Pods are guaranteed. Each Pod is created and deleted in order of its index, ensuring that Pods with larger indices are deleted before Pods with smaller indices, to ensure data stability.
- In Deployment, the creation, deletion, and updating order of Pods are not deterministic. There is no guarantee of order between them, and each Pod may be created, deleted, or updated at any time.
In summary, StatefulSet and Deployment have different characteristics and use cases when managing application replicas. StatefulSet is more suitable for stateful applications that require stable identifiers and persistent storage, while Deployment is more suitable for stateless applications.
DaemonSet
DaemonSet is like a robot assigning tasks to your applications.
Imagine you have a delivery company with many vehicles, each responsible for delivering packages in specific areas. DaemonSet is like giving each vehicle a task list to deliver packages in its assigned area.
For example, suppose your delivery company needs to place a surveillance camera (Pod) on every street in each city (Node). You can use DaemonSet to manage the deployment of these surveillance cameras. DaemonSet ensures that there is one camera running on each node, and this camera only runs on nodes responsible for monitoring, not on other nodes.
Additionally, if your delivery company needs to automatically deploy surveillance cameras when adding a new city, DaemonSet can help you with that task. It automatically deploys cameras on new nodes, ensuring that new cities are also monitored.
In summary, DaemonSet is like a robot assigning tasks to your applications, ensuring that your required applications run on every node as needed and automatically deploying new application replicas as needed.
Service Accounts and RBAC
Service Accounts and RBAC (Role-Based Access Control) are two distinct security mechanisms in Kubernetes, each responsible for managing different levels of permissions and access control.
- Service Accounts:
- Service Accounts are mechanisms in Kubernetes used for identity authentication, allowing Pods or other Kubernetes resources to authenticate and authorize themselves within the cluster.
- Each Pod is associated with a Service Account, representing the Pod’s identity. Service Accounts can be assigned to Pods, enabling them to perform various operations within the cluster, such as communicating with other services, accessing volumes, etc.
- Service Accounts are typically used to identify and differentiate between different applications or services, allowing Kubernetes to recognize and control their behaviors.
- RBAC (Role-Based Access Control):
- RBAC is a mechanism in Kubernetes used to control the access permissions of users or service accounts to cluster resources.
- RBAC allows cluster administrators to define a set of roles, where each role defines a set of permissions (such as read, write, delete, etc.), and then assign these roles to users or service accounts.
- RBAC also allows cluster administrators to define role bindings, associating roles with users or service accounts, to tell Kubernetes who can perform what operations within the cluster.
- RBAC has a broader scope of influence, as it can control the access permissions of users or service accounts to any resource within the cluster, not just limited to identity authentication.
In summary, Service Accounts are primarily used for identity authentication, to identify and differentiate between different applications or services, while RBAC is used to control the access permissions of users or service accounts to cluster resources, achieving fine-grained permission control through defining roles and role bindings. While they serve different functions and scopes of application, both Service Accounts and RBAC play essential roles in ensuring the security and stability of the Kubernetes cluster.
Service Accounts
Service Account is like giving your application an ID card.
Imagine you bring your ID card to handle various tasks, such as opening a bank account, shopping, or verifying identity. In Kubernetes, Service Account plays a similar role. It provides an identity for your application, allowing your application to perform various operations in the cluster, such as creating, deleting, or modifying resources.
For example, suppose your application needs to retrieve data from other services or write data to a database. These operations typically require authentication to ensure that only authorized applications can perform them. Service Account provides this authentication mechanism, ensuring that your application can safely perform operations in the Kubernetes cluster.
Additionally, Service Account can help your application communicate with other Kubernetes resources, such as calling other services, accessing volumes, or monitoring events in the cluster.
In summary, Service Account is like giving your application an ID card, providing authentication and authorization mechanisms for your application to safely perform various operations in the Kubernetes cluster.
RBAC
RBAC is like an access control system for applications.
Imagine you have a large building with many rooms and many people. To protect the security of the building, you install an access control system. This system determines which rooms each person can enter based on their identity and permissions.
In Kubernetes, RBAC plays a similar role. It allows you to set permissions for different users or service accounts to control their access to resources and perform operations. For example, you can set one user to only read Pods in a specific namespace, while another user can read and write all Deployments.
The working principle of RBAC is simple: you define roles and role bindings, and then assign them to users or service accounts. Roles define a set of permissions, such as read, write, delete, etc., while role bindings associate roles with users or service accounts, telling Kubernetes who can do what.
In summary, RBAC is like installing an access control system for your applications, controlling the access and operations of users or service accounts to Kubernetes resources, and protecting the security of your cluster.
