About the Default Affinity and Anti-Affinity Settings for TimesTenClassic Objects
Kubernetes affinity and anti-affinity settings constrain how Pods are scheduled on a Node. See Affinity and anti-affinity in the Kubernetes documentation.
-
A
nodeAffinity
setting that instructs Kubernetes to provision TimesTen Pods on nodes with the proper architecture (eitheramd64
orarm64
). For more information about these architectures, see About Deploying in a Multi-Architecture Kubernetes Cluster in this book. This architecture setting is required. -
A
podAntiAffinity
section that instructs Kubernetes to schedule Pods for a TimesTenClassic object on different nodes, if possible. This section is preferred. Because the anti-affinity setting is preferred (a lesser constraint), Kubernetes can schedule multiple Pods on the same Node if resource constraints make it necessary. For example, although not recommended, an active standby pair of TimesTen databases can be provisioned in a one Node cluster. However, if two or more Nodes are available, Kubernetes attempts to schedule TimesTen Pods on different Nodes.
affinity
section in a TimesTenClassic object definition, the TimesTen Operator uses your affinity
section and does not modify it.
Note:
If you specify anodeAffinity.requiredDuringSchedulingIgnoredDuringExecution
section, the TimesTen Operator adds the arch
clause to it.
The following snippet shows the default affinity and anti-affinity settings for a TimesTenClassic object named sample
.
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/arch
operator: In
values:
- amd64
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- podAffinityTerm:
labelSelector:
matchLabels:
database.timesten.oracle.com: sample
topologyKey: kubernetes.io/hostname
weight: 50