You are designing a resource-sharing policy for applications used by different teams in a Google Kubernetes Engine cluster. You need to ensure that all applications can access the resources needed to run. What should you do? (Choose two.)
You are designing a resource-sharing policy for applications used by different teams in a Google Kubernetes Engine cluster. You need to ensure that all applications can access the resources needed to run. What should you do? (Choose two.)
To ensure that all applications can access the necessary resources in a Google Kubernetes Engine cluster, it is important to manage resource allocation effectively. Creating a namespace for each team and attaching resource quotas to each namespace allows for controlled resource usage, preventing any single team from monopolizing resources. Additionally, creating a LimitRange within each namespace specifies default compute resource requirements, ensuring that resource allocation is standardized and that applications do not request excessive resources. This combination ensures efficient resource sharing and management across different teams.
I vote B, C https://kubernetes.io/docs/concepts/policy/resource-quotas/ https://kubernetes.io/docs/concepts/policy/limit-range/
Yes agree B, C https://cloud.google.com/blog/products/containers-kubernetes/kubernetes-best-practices-resource-requests-and-limits
BC are correct
https://cloud.google.com/blog/products/containers-kubernetes/kubernetes-best-practices-resource-requests-and-limits Ans B,C
A&B as obvious !
why A&B?
I go with B and C. Defining namespaces and Limiting resource quotas for each team in order to avoid resource collisions and hunger.
BC is the answer. https://kubernetes.io/docs/concepts/policy/resource-quotas/ A resource quota, defined by a ResourceQuota object, provides constraints that limit aggregate resource consumption per namespace. It can limit the quantity of objects that can be created in a namespace by type, as well as the total amount of compute resources that may be consumed by resources in that namespace. https://kubernetes.io/docs/concepts/policy/limit-range/ A LimitRange is a policy to constrain the resource allocations (limits and requests) that you can specify for each applicable object kind (such as Pod or PersistentVolumeClaim) in a namespace.
B,C are the right options
B. Create a namespace for each team and attach resource quotas to each namespace. This is a fundamental best practice for multi-tenancy in Kubernetes. Namespaces provide isolation and organization, and resource quotas allow you to control the maximum resources that applications within a namespace can consume. This ensures fair resource allocation and prevents one team from monopolizing resources. C. Create a LimitRange to specify the default compute resource requirements for each namespace. LimitRanges define minimum and maximum resource limits for objects (like Pods) within a namespace. This helps standardize resource usage and prevents applications from requesting excessive resources.
Let's look at why the other options are less ideal: A. Specify the resource limits and requests in the object specifications. While this is important for individual Pods, it doesn't provide a centralized way to manage resource sharing across multiple teams. D. Create a Kubernetes service account (KSA) for each application and assign each KSA to the namespace. Service accounts are for authentication and authorization, not for resource management. E. Use the Anthos Policy Controller to enforce label annotations on all namespaces. Use taints and tolerations to allow resource sharing for namespaces. Anthos Policy Controller is a powerful tool for policy enforcement, but it's not the primary mechanism for managing resource quotas and limits. Taints and tolerations are used for node affinity and scheduling, not for resource allocation.
When it comes to Google's recommended best practices for Kubernetes, especially in the context of Google Kubernetes Engine (GKE), the emphasis is generally placed on setting specific resource requests and limits for each pod and container (Option A). This approach aligns with Kubernetes best practices, as it ensures efficient and reliable operation of applications by maximizing infrastructure utilization and guaranteeing smooth application performance. This granular level of configuration, where resource requests and limits are explicitly set for each workload, is key to operating applications as efficiently and reliably as possible in Kubernetes clusters. It allows for the classification of pods into different Quality of Service (QoS) classes, such as 'Guaranteed' and 'Burstable', which further aids in resource management and scheduling decisions.
Specify the resource limits and requests in the object specifications. This will ensure that each application is allocated the resources it needs to run, and that no application can consume more resources than it was allocated. Create a namespace for each team, and attach resource quotas to each namespace. This will allow you to isolate each team's applications from each other, and to ensure that each team's applications are not consuming more resources than they were allocated.
In the context of the problem statement, B and C are appropriate solution for ensuring that all applications can access the resources needed to run: B. Create a namespace for each team, and attach resource quotas to each namespace. This way, you can set limits on the resources that a team can consume, so that one team does not consume all the resources of the cluster, and that resources are shared among all teams in a fair way. C. Create a LimitRange to specify the default compute resource requirements for each namespace. LimitRanges allow you to set default limits and requests for all the pods in a specific namespace, it also ensure that pods in that namespace can never consume more resources than the LimitRange defined. You can use a combination of resource limits, quotas, and limit ranges to prevent a single team or application from consuming too many resources, as well as to ensure that all teams and applications have access to the resources they need to run.
Option A: Specify the resource limits and requests in the object specifications, is a valid method for controlling the resources that a pod or container needs, but it may not be sufficient by itself to fully manage the resources in a multi-tenant cluster where multiple teams and applications need to share resources. When you set resource limits and requests on the pod or container level, you have a fine-grained control over the resources that a specific pod or container needs, but it doesn't provide a way to set limits or quotas on the level of a whole team or namespace. It also doesn't provide a default configuration for all pods created in a namespace. By itself, this method does not give you the visibility and control you need over the overall resource usage across multiple teams and applications. With creating a namespace per team and attaching quotas, you can limit the resources each team can use, and with LimitRange you can ensure that no pod created in the namespace can go beyond specific limits.
I will go with B and C.
A, B LimitRanges are great and all, but they don't actually guarantee that running containers have the resources available that they need, since they're not object-specific.