TAINT_KEY: 노드의 호스트 이름 또는 톨러레이션(toleration)이 적용되는 로컬에서 추론된 다른 값과 같은 taint 키의 기존 고유한 이름입니다. 노드에 이미 taint 키가 정의되어 있습니다. 빈 필드와 OPERATOR_VALUE가 exists로 설정된 경우 톨러레이션(toleration)이 모든 값과 모든 키와 일치해야 함을 나타냅니다.
OPERATOR_VALUE: 키와 값 집합의 관계를 나타냅니다. 파라미터를 다음 중 하나로 설정합니다.
exists: Kubernetes는 taint의 값과 관계없이 taint가 정의된 경우 모든 값과 일치합니다.
equal: 값이 다른 경우 Kubernetes는 포드를 노드에 예약하지 않습니다. 이 연산자에는 taint true 값이 필요합니다.
VALUE: 톨러레이션(toleration)이 일치할 taint 값입니다. 연산자가 Exists인 경우 값은 비어 있고, 그렇지 않으면 일반 문자열입니다. 예를 들면 true입니다.
TAINT_EFFECT: 일치할 taint 효과를 나타냅니다. 빈 필드는 모든 taint 효과가 일치해야 함을 나타냅니다. 파라미터를 다음 중 하나로 설정합니다.
NoSchedule: Kubernetes는 taint가 적용된 노드에 새 포드를 예약하지 않습니다.
PreferNoSchedule: Kubernetes는 필요한 경우가 아니라면 taint가 적용된 노드에 새 포드를 배치하지 않습니다.
NoExecute: Kubernetes는 taint를 허용하지 않는 기존 Pod를 제거합니다.
매니페스트를 다시 적용합니다.
노드 어피니티 정의
Kubernetes 스케줄러는 노드 어피니티를 일련의 규칙으로 사용하여 포드를 배치할 위치를 결정합니다. 노드 어피니티는 노드 선택기의 더 유연하고 표현력이 뛰어난 버전입니다.
데이터베이스 실행을 위해 예약해야 하는 노드를 지정하려면 다음 단계를 따르세요.
기본 인스턴스의 경우 primarySpec의 schedulingConfig 섹션 또는 읽기 풀 인스턴스의 경우 spec의 tolerations 섹션 뒤에 nodeaffinity 섹션을 포함하도록 데이터베이스 클러스터 매니페스트를 수정합니다.
requiredDuringSchedulingIgnoredDuringExecution: Kubernetes는 정의된 규칙에 따라 정확하게 포드를 예약합니다.
preferredDuringSchedulingIgnoredDuringExecution: Kubernetes 스케줄러는 정의된 예약 규칙을 충족하는 노드를 찾으려고 시도합니다. 그러나 이러한 노드가 없으면 Kubernetes는 클러스터의 다른 노드로 예약합니다.
WAIT_VALUE: 지정된 노드의 선호도 가중치를 나타냅니다. 값이 클수록 선호도가 더 강합니다. 유효한 값은 1부터 100까지입니다.
LABEL_KEY: 위치 표시기 역할을 하고 클러스터 전반에서 균일한 포드 분산을 용이하게 하는 키의 노드 라벨입니다. 예를 들면 disktype=ssd입니다.
OPERATOR_VALUE: 키와 값 집합의 관계를 나타냅니다. 파라미터를 다음 중 하나로 설정합니다.
In: 값 배열은 비어 있지 않아야 합니다.
NotIn: 값 배열은 비어 있지 않아야 합니다.
Exists: 값 배열은 비어 있어야 합니다.
DoesNotExist: 값 배열은 비어 있어야 합니다.
Gt: 값 배열에는 정수로 해석되는 단일 요소가 있어야 합니다.
Lt: 값 배열에는 정수로 해석되는 단일 요소가 있어야 합니다.
LABEL_KEY_VALUE: 라벨 키의 값입니다. 다음과 같이 파라미터를 문자열 값 배열로 설정합니다.
연산자가 In 또는 NotIn인 경우 값 배열은 비어 있지 않아야 합니다.
연산자가 Exists 또는 DoesNotExist인 경우 값 배열은 비어 있어야 합니다.
연산자가 Gt 또는 Lt인 경우 값 배열에는 정수로 해석되는 단일 요소가 있어야 합니다.
매니페스트를 다시 적용합니다.
예
다음 예는 AlloyDB Omni Kubernetes 연산자 기본 인스턴스와 읽기 풀 인스턴스에서 Pod를 예약하는 방법을 보여줍니다. 이러한 예약 설정을 사용하면 데이터베이스 클러스터의 기본 인스턴스가 적절한 노드에 예약되는 동시에 노드 선택의 유연성을 어느 정도 허용할 수 있습니다. 이러한 유연성은 부하를 분산하거나, 리소스 사용량을 최적화하거나, 특정 노드 역할 및 특성을 준수하는 데 유용할 수 있습니다.
다음 세부정보로 인해 컨트롤 플레인 노드로 표시된 노드에 포드를 예약할 수 있는 톨러레이션(toleration) 예시입니다.
node-role.kubernetes.io/control-plane taint 키는 노드에 컨트롤 플레인 노드가 있음을 나타냅니다.
Exists 연산자는 값에 관계없이 지정된 taint 키가 있는 모든 taint와 톨러레이션(toleration)이 일치함을 의미합니다.
NoSchedule 효과는 일치하는 톨러레이션(toleration)이 없는 한 포드가 컨트롤 플레인 노드에 예약되지 않는다는 것을 의미합니다.
preferredDuringSchedulingIgnoredDuringExecution 노드 어피니티 유형은 노드 어피니티에 정의된 규칙이 선호되지만 예약 중에 필수는 아니라고 지정합니다. 선호하는 노드를 사용할 수 없는 경우에도 포드는 다른 노드에 예약될 수 있습니다. 1 가중치 값은 약한 선호도를 나타냅니다. 노드 선택 기준은 preference 섹션에 정의되어 있습니다. matchExpressions 섹션에는 노드를 일치시키는 데 사용되는 표현식 배열이 포함됩니다. another-node-label-key 키는 일치시킬 노드 라벨의 키를 나타냅니다. In 연산자는 노드에 지정된 값 중 하나가 포함된 키가 있어야 함을 의미합니다. another-node-label-key 키에는 another-node-label-value 값이 있어야 합니다.
노드 어피니티 규칙의 예는 another-node-label-value 값이 있는 another-node-label-key 라벨이 있는 노드에서 Pod를 예약하는 것을 선호한다고 나타냅니다. 이 환경설정은 약하므로 강력한 요구사항은 아닙니다.
이 예에서는 다음을 결합합니다.
NoSchedule taint를 허용하여 컨트롤 플레인 노드에 포드를 예약할 수 있는 톨러레이션(toleration)입니다.
특정 라벨이 있는 노드를 선호하지만 엄격하게 요구하지는 않는 노드 어피니티입니다. 따라서 예약 시 유연성을 제공합니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-04(UTC)"],[[["\u003cp\u003eScheduling in AlloyDB Omni Kubernetes Operator involves matching database Pods to nodes based on criteria like CPU and memory, aiming to balance node distribution and optimize performance.\u003c/p\u003e\n"],["\u003cp\u003eTolerations can be specified in the AlloyDB Omni manifest to allow Pods to be scheduled on nodes with specific taints, enabling control over where Pods are placed based on node characteristics.\u003c/p\u003e\n"],["\u003cp\u003eNode affinity rules in the manifest help direct the Kubernetes scheduler to place Pods on desired nodes, using either required or preferred rules, offering flexibility in node selection.\u003c/p\u003e\n"],["\u003cp\u003eThe \u003ccode\u003etolerations\u003c/code\u003e section in the \u003ccode\u003eschedulingConfig\u003c/code\u003e in the manifest allows Pods to tolerate specific taints on nodes, using parameters such as \u003ccode\u003ekey\u003c/code\u003e, \u003ccode\u003eoperator\u003c/code\u003e, \u003ccode\u003evalue\u003c/code\u003e, and \u003ccode\u003eeffect\u003c/code\u003e to precisely define the matching criteria.\u003c/p\u003e\n"],["\u003cp\u003eThe \u003ccode\u003enodeaffinity\u003c/code\u003e section allows for the definition of rules that can dictate whether scheduling to certain nodes is required or preferred, and can use a wide range of label operators, such as \u003ccode\u003eIn\u003c/code\u003e, \u003ccode\u003eNotIn\u003c/code\u003e, \u003ccode\u003eExists\u003c/code\u003e, \u003ccode\u003eDoesNotExist\u003c/code\u003e, \u003ccode\u003eGt\u003c/code\u003e, and \u003ccode\u003eLt\u003c/code\u003e to match nodes with desired characteristics.\u003c/p\u003e\n"]]],[],null,["# Assign nodes to a database cluster using scheduling\n\nSelect a documentation version: 15.5.5keyboard_arrow_down\n\n- [Current (16.8.0)](/alloydb/omni/current/docs/assign-nodes-cluster-scheduling)\n- [16.8.0](/alloydb/omni/16.8.0/docs/assign-nodes-cluster-scheduling)\n- [16.3.0](/alloydb/omni/16.3.0/docs/assign-nodes-cluster-scheduling)\n- [15.12.0](/alloydb/omni/15.12.0/docs/assign-nodes-cluster-scheduling)\n- [15.7.1](/alloydb/omni/15.7.1/docs/assign-nodes-cluster-scheduling)\n- [15.7.0](/alloydb/omni/15.7.0/docs/assign-nodes-cluster-scheduling)\n- [15.5.5](/alloydb/omni/15.5.5/docs/assign-nodes-cluster-scheduling)\n- [15.5.4](/alloydb/omni/15.5.4/docs/assign-nodes-cluster-scheduling)\n\n\u003cbr /\u003e\n\nIn [AlloyDB Omni Kubernetes Operator](/alloydb/omni/15.5.5/docs/deploy-kubernetes), *scheduling* is a process for matching new database Pods to nodes to balance node distribution across the cluster and help optimize performance. Pods and nodes are matched based on several criteria and available resources, such as CPU and memory.\n\n\u003cbr /\u003e\n\nFor more information about scheduling, see [Scheduling, Preemption and Eviction](https://kubernetes.io/docs/concepts/scheduling-eviction/) in the Kubernetes documentation.\n\nThis page shows how to specify tolerations and node affinity scheduling configurations for primary and read pool instances in your Kubernetes manifest.\n\nFor information about how to define *taints* on nodes, see\n[Taints and Tolerations](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/#concepts)\nin the Kubernetes documentation.\n\nSpecify tolerations\n-------------------\n\nTo schedule your AlloyDB Omni Pods to nodes free of other application Pods or match a specific *taint* defined on those nodes, apply one or more tolerations to the nodes as follows:\n\n1. Modify the AlloyDB Omni Kubernetes Operator cluster's manifest to include a `tolerations` section in the `schedulingConfig` section of either of the following sections:\n - `primarySpec` for primary instances\n - `spec` for read pool instances\n\n ```\n tolerations:\n - key: \"TAINT_KEY\"\n operator: \"OPERATOR_VALUE\"\n value: \"VALUE\"\n effect: \"TAINT_EFFECT\"\n \n ```\n\n Replace the following:\n - \u003cvar translate=\"no\"\u003eTAINT_KEY\u003c/var\u003e: The existing unique name of the taint key such as a node's hostname or another locally-inferred value that the toleration applies to. The taint key is already defined on a node. An empty field and the \u003cvar translate=\"no\"\u003eOPERATOR_VALUE\u003c/var\u003e set to `exists` signify that the toleration must match all values and all keys.\n - \u003cvar translate=\"no\"\u003eOPERATOR_VALUE\u003c/var\u003e: Represents a key's relationship to a set of values. Set the parameter to one of the following:\n - `exists`: Kubernetes matches any value if the taint is defined regardless of the taint's value.\n - `equal`: Kubernetes does not schedule a Pod to a node if the values are different. The operator requires the taint `true` value.\n - \u003cvar translate=\"no\"\u003eVALUE\u003c/var\u003e: The taint value the toleration matches to. If the operator is Exists, the value is empty, otherwise it is a regular string. For example, `true`.\n - \u003cvar translate=\"no\"\u003eTAINT_EFFECT\u003c/var\u003e: Indicates the taint effect to match. An empty field signifies that all taint effects must be matched. Set the parameter to one of the following:\n - `NoSchedule`: Kubernetes does not schedule new Pods on the tainted node.\n - `PreferNoSchedule`: Kubernetes avoids placing new Pods on the tainted node unless necessary.\n - `NoExecute`: Kubernetes evicts existing Pods that don't tolerate the taint.\n2. Re-apply the manifest.\n\nDefine node affinity\n--------------------\n\nThe Kubernetes scheduler uses node affinity as a set of rules to determine where to place a Pod. Node affinity is a more flexible and expressive version of node selectors.\n\nTo specify which nodes must be scheduled for running your database, follow these steps:\n\n1. Modify the database cluster manifest to include the `nodeaffinity`section after the `tolerations` section in the `schedulingConfig` section of either `primarySpec` for primary instances or `spec` for read pool instances: \n\n ```\n nodeaffinity:\n NODE_AFFINITY_TYPE:\n - weight: WAIT_VALUE\n preference:\n matchExpressions:\n - key: LABEL_KEY\n operator: OPERATOR_VALUE\n values:\n - LABEL_KEY_VALUE\n \n ```\n\n Replace the following:\n - \u003cvar translate=\"no\"\u003eNODE_AFFINITY_TYPE\u003c/var\u003e: Set the parameter to one of the following:\n - `requiredDuringSchedulingIgnoredDuringExecution`: Kubernetes schedules the Pod based exactly on the defined rules.\n - `preferredDuringSchedulingIgnoredDuringExecution`: The Kubernetes scheduler tries to find a node that meets the defined rule for scheduling. However, if there is no such node, Kubernetes schedules to a different node in the cluster.\n - \u003cvar translate=\"no\"\u003eWAIT_VALUE\u003c/var\u003e: Indicates the preference weight for the specified nodes. Higher values indicate a stronger preference. Valid values are from `1` to `100`.\n - \u003cvar translate=\"no\"\u003eLABEL_KEY\u003c/var\u003e: The node's label for the key that serves as a location indicator and facilitates even Pod distribution across the cluster. For example, `disktype=ssd`.\n - \u003cvar translate=\"no\"\u003eOPERATOR_VALUE\u003c/var\u003e: Represents a key's relationship to a set of values. Set the parameter to one of the following:\n - `In`: The values array must be non-empty.\n - `NotIn`: The values array must be non-empty.\n - `Exists`: The values array must be empty.\n - `DoesNotExist`: The values array must be empty.\n - `Gt`: The values array must have a single element, which is interpreted as an integer.\n - `Lt`: The values array must have a single element, which is interpreted as an integer.\n - \u003cvar translate=\"no\"\u003eLABEL_KEY_VALUE\u003c/var\u003e: The value for your label key. Set the parameter to an array of string values as follows:\n - If the operator is `In` or `NotIn`, the values array must be non-empty.\n - If the operator is `Exists` or `DoesNotExist`, the values array must be empty.\n - If the operator is `Gt` or `Lt`, the values array must have a single element, which is interpreted as an integer.\n2. Reapply the manifest.\n\nExample\n-------\n\nThe following example illustrates scheduling Pods in AlloyDB Omni Kubernetes Operator primary and read pool instances. Such scheduling setup helps ensure that the primary instance of the database cluster is scheduled on appropriate nodes while allowing some flexibility in node selection. This flexibility can be useful for balancing load, optimizing resource usage, or adhering to specific node roles and characteristics. \n\n schedulingconfig:\n tolerations:\n - key: \"node-role.kubernetes.io/control-plane\"\n operator: \"Exists\"\n effect: \"NoSchedule\"\n nodeaffinity:\n preferredDuringSchedulingIgnoredDuringExecution:\n - weight: 1\n preference:\n matchExpressions:\n - key: another-node-label-key\n operator: In\n values:\n - another-node-label-value\n\nThe example toleration allows the Pod to be scheduled on nodes that are marked as control plane nodes because of the following details:\n\n- The `node-role.kubernetes.io/control-plane` taint key indicates that the node has a control plane node.\n- The `Exists` operator means that the toleration matches any taint with the specified taint key regardless of the value.\n- The `NoSchedule` effect means that Pods aren't going to be scheduled on the control plane node unless they have a matching toleration.\n\nThe `preferredDuringSchedulingIgnoredDuringExecution` node affinity type specifies that the rules defined for the node affinity are preferred but are not required during scheduling. If the preferred nodes are not available, the Pod might still be scheduled on other nodes. The `1` weight value indicates a weak preference. Node selection criteria are defined in the `preference` section. The `matchExpressions` section contains an array of expressions used to match nodes. The `another-node-label-key` key represents the key of the node label to match. The `In` operator means the node must have the key with one of the specified values. The `another-node-label-key` key must have the `another-node-label-value` value.\n\nThe example node affinity rule indicates a preference for scheduling the Pod on nodes that have the `another-node-label-key` label with the `another-node-label-value` value. The preference is weak so it's not a strong requirement.\n\nThe example combines the following:\n\n- Tolerations that allow the Pod to be scheduled on control plane nodes by tolerating the `NoSchedule` taint.\n- A node affinity that prefers nodes with a specific label but does not strictly require it; hence, it offers flexibility in scheduling.\n\nWhat's next\n-----------\n\n- [Set up AlloyDB Omni for production](/alloydb/omni/15.5.5/docs/configure-omni)"]]
