github.com/1aal/kubeblocks@v0.0.0-20231107070852-e1c03e598921/docs/user_docs/resource-scheduling/resource-scheduling.md (about) 1 --- 2 title: Configure pod affinity for database clusters 3 description: How to configure pod affinity for database clusters 4 keywords: [pod affinity] 5 sidebar_position: 1 6 --- 7 8 # Configure pod affinity for database clusters 9 10 Affinity controls the selection logic of pod allocation on nodes. By a reasonable allocation of Kubernetes pods on different nodes, the business availability, resource usage rate, and stability are improved. 11 12 Affinity and toleration can be set by `kbcli` or the CR YAML file of the cluster. `kbcli` only supports the cluster-level configuration and the CR YAML file supports both the cluster-level and component-level configurations. 13 14 ## Option 1. Use kbcli 15 16 Run `kbcli cluster create -h` to view the examples and the parameter options of affinity and toleration configurations. 17 18 ```bash 19 kbcli cluster create -h 20 > 21 Create a cluster 22 23 Examples: 24 ...... 25 26 # Create a cluster forced to scatter by node 27 kbcli cluster create --cluster-definition apecloud-mysql --topology-keys kubernetes.io/hostname --pod-anti-affinity 28 Required 29 30 # Create a cluster in specific labels nodes 31 kbcli cluster create --cluster-definition apecloud-mysql --node-labels 32 '"topology.kubernetes.io/zone=us-east-1a","disktype=ssd,essd"' 33 34 # Create a Cluster with two tolerations 35 kbcli cluster create --cluster-definition apecloud-mysql --tolerations 36 '"key=engineType,value=mongo,operator=Equal,effect=NoSchedule","key=diskType,value=ssd,operator=Equal,effect=NoSchedule"' 37 38 # Create a cluster, with each pod runs on their own dedicated node 39 kbcli cluster create --tenancy=DedicatedNode 40 41 Options: 42 ...... 43 --node-labels=[]: 44 Node label selector 45 46 --pod-anti-affinity='Preferred': 47 Pod anti-affinity type, one of: (Preferred, Required) 48 49 --tenancy='SharedNode': 50 Tenancy options, one of: (SharedNode, DedicatedNode) 51 52 --tolerations=[]: 53 Tolerations for cluster, such as '"key=engineType,value=mongo,operator=Equal,effect=NoSchedule"' 54 55 --topology-keys=[]: 56 Topology keys for affinity 57 ...... 58 ....... 59 ``` 60 61 ## Option 2. Use a YAML file 62 63 You can configure pod affinity and toleration in either the spec of a cluster or the spec of a component. 64 65 The cluster-level configuration is used as the default configuration of all components; if the pod affinity configuration exists in a component, the component-level configuration will take effect and cover the default cluster-level configuration. 66 67 ```yaml 68 spec: 69 affinity: 70 podAntiAffinity: Preferred 71 topologyKeys: 72 - kubernetes.io/hostname 73 nodeLabels: 74 topology.kubernetes.io/zone: us-east-1a 75 tenancy: SharedNode 76 tolerations: 77 - key: EngineType 78 operator: Equal 79 value: mysql 80 effect: NoSchedule 81 componentSpecs: 82 - name: mysql 83 componentDefRef: mysql 84 affinity: 85 podAntiAffinity: Required 86 topologyKeys: 87 - kubernetes.io/hostname 88 ...... 89 ``` 90 91 **Description of parameters in the YAML file** 92 93 * Affinity 94 Parameters related to pod affinity are under the object of `spec.affinity` in the Cluster CR YAML file. 95 The pod affinity configuration can be applied to the cluster or component and the component-level configuration covers the cluster-level configuration. 96 97 * Toleration 98 Parameters related to toleration are under the object of `spec.tolerations` in the Cluster CR YAML file and Kubernetes native semantics are used. For the toleration parameter configuration, refer to the Kubernetes official document [Taints and Tolerations](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/). 99 Like affinity configuration, toleration also supports component-level and cluster-level configurations. The cluster-level configuration is set as default and the component-level configuration covers the cluster-level configuration. 100 101 | **Parameter** | **Value** | **Description** | 102 | :-- | :-- | :-- | 103 | podAntiAffinity | - Required <br/> - Preferred (default) | It stands for the anti-affinity level of the pod under the current component.<br/> - Required means pods must be spread evenly in the fault domain specified by `topologyKeys`. <br/> - Preferred means pods can be spread as evenly as possible in the fault domain specified by `topologyKeys`. | 104 | topologyKeys | | TopologyKey is the key of the node label. The node with the same value as this key is considered to be in the same topology, i.e. the same fault domain.<br/>For example, if the TopologyKey is `kubernetes.io/hostname`, every node is a domain of this topology. If the TopologyKey is `topology.kubernetes.io/zone`, every available zone is a domain of this topology. | 105 | nodeLabels | | NodeLabels specifies a pod can only be scheduled to the node with the specified node label. | 106 | tenancy | - SharedNode (default) <br/> - DedicatedNode | It refers to the pod tenancy type:<br/> - SharedNode means that multiple pods share a node.<br/> - DedicatedNode means that a node is dedicated to a pod. | 107 108 ## Examples 109 110 The following examples use `kbcli` to create cluster instances and show the common situations of how to use pod affinity and toleration configuration. 111 112 ### Default configuration 113 114 No affinity parameters are required. 115 116 ### Spread evenly as much as possible 117 118 You can configure the pod affinity as "Preferred" if you want the pods of the cluster to be deployed in different topological domains, but do not want deployment failure due to failing to meet distribution requirements. 119 The example below creates and sets a cluster to be deployed evenly across nodes as much as possible. 120 121 ```bash 122 kbcli cluster create --topology-keys kubernetes.io/hostname --pod-anti-affinity Preferred 123 ``` 124 125 ### Forced spread evenly 126 127 You can configure the pod affinity as "Required" if the pods of the cluster must be deployed in different topological domains to ensure that the cluster can be disaster-tolerant across topological domains. 128 The example below creates and sets a cluster that must be deployed across nodes. 129 130 ```bash 131 kbcli cluster create --topology-keys kubernetes.io/hostname --pod-anti-affinity Required 132 ``` 133 134 ### Deploy pods in specified nodes 135 136 You can specify a node label to deploy a cluster on the specified node. 137 The example below creates and sets a cluster to be deployed on the node with an available zone label of `topology.kubernetes.io/zone=us-east-1a`. 138 139 ```bash 140 kbcli cluster create --node-labels '"topology.kubernetes.io/zone=us-east-1a"' 141 ``` 142 143 ### Deploy pods in dedicated nodes 144 145 If you want to manage node groups by the taint and node labels and need the clusters to be deployed on a dedicated host group, you can set tolerations and specify a node label. 146 147 For example, you have a host group for deploying database clusters and this host is added with a taint named `database=true:NoSchedule` and a label `database=true`, then you can follow the command below to create a cluster. 148 149 ```bash 150 kbcli cluster create --node-labels '"databa=true"' --tolerations '"key=database,value=true,operator=Equal,effect=NoSchedule" 151 ``` 152 153 ### One node only for one pod 154 155 If you need one cluster only for the online core business and need to ensure every pod of this cluster has its own node to avoid being affected by the cluster of the cluster, you can specify `tenancy` as "DedicatedNode". 156 157 ```bash 158 kbcli cluster create --tenancy=DedicatedNode 159 ``` 160 161 :::note 162 163 This command will be performed successfully based on the prerequisite that you have added taints for these nodes. Otherwise, the business that is not managed by KubeBlocks can still be deployed on these nodes. 164 165 :::