Downloaded 33 times
![Scheduling Controlled | Pod Affinity Terms
• topologyKey – nodes’ label key defining co-location
• labelSelector and namespaces – select group of pods
<pod affinity term>:
topologyKey: <topology label key>
namespaces: [ <namespace>, ... ]
labelSelector:
matchLabels:
<label key>: <label value>
...
matchExpressions:
- key: <label key>
operator: In | NotIn | Exists | DoesNotExist
values: [ <value 1>, ... ]
...
@olgch; @kublr](https://image.slidesharecdn.com/202004advancedschedulinginkubernetes-201016200901/85/Advanced-Scheduling-in-Kubernetes-39-320.jpg)
![Default Scheduler | Custom Policy Config
{
"kind" : "Policy",
"apiVersion" : "v1",
"predicates" : [
{"name" : "PodFitsHostPorts"},
...
{"name" : "HostName"}
],
"priorities" : [
{"name" : "LeastRequestedPriority", "weight" : 1},
...
{"name" : "EqualPriority", "weight" : 1}
],
"hardPodAffinitySymmetricWeight" : 10,
"alwaysCheckAllPredicates" : false
}
@olgch; @kublr](https://image.slidesharecdn.com/202004advancedschedulinginkubernetes-201016200901/85/Advanced-Scheduling-in-Kubernetes-44-320.jpg)
![Default Scheduler | Scheduler WebHook
{
"kind" : "Policy",
"apiVersion" : "v1",
"predicates" : [...],
"priorities" : [...],
"extenders" : [{
"urlPrefix": "http://127.0.0.1:12346/scheduler",
"filterVerb": "filter",
"bindVerb": "bind",
"prioritizeVerb": "prioritize",
"weight": 5,
"enableHttps": false,
"nodeCacheCapable": false
}],
"hardPodAffinitySymmetricWeight" : 10,
"alwaysCheckAllPredicates" : false
}
@olgch; @kublr](https://image.slidesharecdn.com/202004advancedschedulinginkubernetes-201016200901/85/Advanced-Scheduling-in-Kubernetes-45-320.jpg)
![Use Case | Distributed Pods
apiVersion: v1
kind: Pod
metadata:
name: db-replica-3
labels:
component: db
spec:
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- topologyKey: kubernetes.io/hostname
labelSelector:
matchExpressions:
- key: component
operator: In
values: [ "db" ]
Node 2
db-replica-2
Node 1
Node 3
db-replica-1
db-replica-3
@olgch; @kublr](https://image.slidesharecdn.com/202004advancedschedulinginkubernetes-201016200901/85/Advanced-Scheduling-in-Kubernetes-51-320.jpg)
![Use Case | Co-located Pods
apiVersion: v1
kind: Pod
metadata:
name: app-replica-1
labels:
component: web
spec:
affinity:
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- topologyKey: kubernetes.io/hostname
labelSelector:
matchExpressions:
- key: component
operator: In
values: [ "db" ]
Node 2
db-replica-2
Node 1
Node 3
db-replica-1
app-replica-1
@olgch; @kublr](https://image.slidesharecdn.com/202004advancedschedulinginkubernetes-201016200901/85/Advanced-Scheduling-in-Kubernetes-52-320.jpg)
Uploaded byKublr
Advanced Scheduling in Kubernetes
The document presents an overview of advanced scheduling techniques in Kubernetes, discussing the scheduling algorithm, controls, and techniques used to manage resource allocation for pods across nodes. Key topics include resource filters, volume constraints, inter-pod affinity, and the configuration of custom schedulers. Use cases highlighting distributed and co-located pods, as well as strategies for managing reliable services on spot nodes, are also explored.
More Related Content
Similar to Advanced Scheduling in Kubernetes
Advanced Scheduling in Kubernetes
- 1. Advanced Scheduling inKubernetes Oleg Chunikhin | CTO, Kublr
- 2. Introductions Oleg Chunikhin CTO, Kublr •20 years in software architecture & development • Working w/ Kubernetes since its release in 2015 • Software architect behind Kublr—an enterprise ready container management platform • Twitter @olgch
- 3. Enterprise Kubernetes Needs DevelopersSRE/Ops/DevOps/SecOps • Self-service • Compatible • Conformant • Configurable • Open & Flexible • Governance • Org multi-tenancy • Single pane of glass • Operations • Monitoring • Log collection • Image management • Identity management • Security • Reliability • Performance • Portability @olgch; @kublr
- 4. @olgch; @kublr Automation Ingress Custom Clusters Infrastructure Logging Monitoring Observability API Usage Reporting RBACIAM Air Gap TLS Certificate Rotation Audit Storage Networking Container Registry CI / CD App Mgmt Infrastructure Container Runtime Kubernetes OPERATIONS SECURITY & GOVERNANCE
- 5. What’s in theslides • Kubernetes overview • Scheduling algorithm • Scheduling controls • Advanced scheduling techniques • Examples, use cases, and recommendations @olgch; @kublr
- 6. Kubernetes | Nodesand Pods Node2 Pod A-2 10.0.1.5 Cnt1 Cnt2 Node 1 Pod A-1 10.0.0.3 Cnt1 Cnt2 Pod B-1 10.0.0.8 Cnt3 @olgch; @kublr
- 7. Kubernetes | ContainerOrchestration Node 1 Docker Kubelet K8S Master API K8S Scheduler(s) Pod A Pod B K8S Controller(s) User Node 1 Pod A Pod B Node 2 Pod C @olgch; @kublr
- 8. Kubernetes | ContainerOrchestration Node 1 Docker Kubelet K8S Master API K8S Scheduler(s) K8S Controller(s) User It all starts empty @olgch; @kublr
- 9. Kubernetes | ContainerOrchestration Node 1 Docker Kubelet K8S Master API K8S Scheduler(s) K8S Controller(s) User Kubelet registers node object in master @olgch; @kublr
- 10. Kubernetes | ContainerOrchestration Node 1 Docker Kubelet K8S Master API K8S Scheduler(s) K8S Controller(s) User Node 1 Node 2 @olgch; @kublr
- 11. Kubernetes | ContainerOrchestration Node 1 Docker Kubelet K8S Master API K8S Scheduler(s) K8S Controller(s) User Node 1 Node 2 User creates (unscheduled) Pod object(s) in Master Pod A Pod B Pod C @olgch; @kublr
- 12. Kubernetes | ContainerOrchestration Node 1 Docker Kubelet K8S Master API K8S Scheduler(s) K8S Controller(s) User Node 1 Node 2 Scheduler notices unscheduled Pods ... Pod A Pod B Pod C @olgch; @kublr
- 13. Kubernetes | ContainerOrchestration Node 1 Docker Kubelet K8S Master API K8S Scheduler(s) K8S Controller(s) User Node 1 Node 2 …identifies the best node to run them on… Pod A Pod B Pod C @olgch; @kublr
- 14. Kubernetes | ContainerOrchestration Node 1 Docker Kubelet K8S Master API K8S Scheduler(s) K8S Controller(s) User Node 1 Node 2 …and marks the pods as scheduled on corresponding nodes. Pod A Pod B Pod C @olgch; @kublr
- 15. Kubernetes | ContainerOrchestration Node 1 Docker Kubelet K8S Master API K8S Scheduler(s) K8S Controller(s) User Node 1 Node 2 Kubelet notices pods scheduled to its nodes… Pod A Pod B Pod C @olgch; @kublr
- 16. Kubernetes | ContainerOrchestration Node 1 Docker Kubelet K8S Master API K8S Scheduler(s) K8S Controller(s) User Node 1 Node 2 … starts pods’ containers. Pod A Pod B Pod C Pod A Pod B @olgch; @kublr
- 17. Kubernetes | ContainerOrchestration Node 1 Docker Kubelet K8S Master API K8S Scheduler(s) K8S Controller(s) User Node 1 Node 2 … and reports pods as “running” to master. Pod A Pod B Pod C Pod A Pod B @olgch; @kublr
- 18. Kubernetes | ContainerOrchestration Node 1 Docker Kubelet K8S Master API K8S Scheduler(s) K8S Controller(s) User Node 1 Node 2 Scheduler finds the best node to run pods. HOW? Pod A Pod B Pod C Pod A Pod B @olgch; @kublr
- 19. Kubernetes | SchedulingAlgorithm For each pod that needs scheduling: 1. Filter nodes 2. Calculate nodes priorities 3. Schedule pod if possible @olgch; @kublr
- 20. Kubernetes | SchedulingAlgorithm Volume filters • Do pod requested volumes’ zones fit the node’s zone? • Can the node attach the volumes? • Are there mounted volumes conflicts? • Are there additional volume topology constraints? Volume filters Resource filters Topology filters Prioritization @olgch; @kublr
- 21. Kubernetes | SchedulingAlgorithm Resource filters • Does pod requested resources (CPU, RAM GPU, etc) fit the node’s available resources? • Can pod requested ports be opened on the node? • Is there no memory or disk pressure on the node? Volume filters Resource filters Topology filters Prioritization @olgch; @kublr
- 22. Kubernetes | SchedulingAlgorithm Topology filters • Is Pod requested to run on this node? • Are there inter-pod affinity constraints? • Does the node match Pod’s node selector? • Can Pod tolerate node’s taints Volume filters Resource filters Topology filters Prioritization @olgch; @kublr
- 23. Kubernetes | SchedulingAlgorithm Prioritize with weights for: • Pod replicas distribution • Least (or most) node utilization • Balanced resource usage • Inter-pod affinity priority • Node affinity priority • Taint toleration priority Volume filters Resource filters Topology filters Prioritization @olgch; @kublr
- 24. Scheduling | ControllingPods Destination • Resource requirements • Be aware of volumes • Node constraints • Affinity and anti-affinity • Priorities and Priority Classes • Scheduler configuration • Custom / multiple schedulers @olgch; @kublr
- 25. Scheduling Controlled |Resources • CPU, RAM, other (GPU) • Requests and limits • Reserved resources kind: Node status: allocatable: cpu: "4" memory: 8070796Ki pods: "110" capacity: cpu: "4" memory: 8Gi pods: "110" kind: Pod spec: containers: - name: main resources: requests: cpu: 100m memory: 1Gi @olgch; @kublr
- 26. Scheduling Controlled |Volumes • Request volumes in the right zones • Make sure node can attach enough volumes • Avoid volume location conflicts • Use volume topology constraints Node 1 Pod A Node 2 Volume 2 Pod B Unschedulable Zone A Pod C Requested Volume Zone B @olgch; @kublr
- 27. Scheduling Controlled |Volumes • Request volumes in the right zones • Make sure node can attach enough volumes • Avoid volume location conflicts • Use volume topology constraints Node 1 Pod A Volume 2Pod B Pod C Requested Volume Volume 1 @olgch; @kublr
- 28. Scheduling Controlled |Volumes • Request volumes in the right zones • Make sure node can attach enough volumes • Avoid volume location conflicts • Use volume topology constraints Node 1 Volume 1Pod A Node 2 Volume 2Pod B Pod C @olgch; @kublr
- 29. Scheduling Controlled |Volumes • Request volumes in the right zones • Make sure node can attach enough volumes • Avoid volume location conflicts • Use volume topology constraints apiVersion: v1 kind: PersistentVolume metadata: name: pv spec: ... nodeAffinity: required: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname operator: In values: - example-node @olgch; @kublr
- 30. Scheduling Controlled |Constraints • Host constraints • Labels and node selectors • Taints and tolerations Node 1Pod A kind: Pod spec: nodeName: node1 kind: Node metadata: name: node1 @olgch; @kublr
- 31. Scheduling Controlled |Node Constraints • Host constraints • Labels and node selectors • Taints and tolerations Node 1 Pod A Node 2 Node 3 label: tier: backend kind: Node metadata: labels: tier: backend kind: Pod spec: nodeSelector: tier: backend @olgch; @kublr
- 32. Scheduling Controlled |Node Constraints • Host constraints • Labels and node selectors • Taints and tolerations kind: Pod spec: tolerations: - key: error value: disk operator: Equal effect: NoExecute tolerationSeconds: 60 kind: Node spec: taints: - effect: NoSchedule key: error value: disk timeAdded: null Pod B Node 1 tainted Pod A tolerate @olgch; @kublr
- 33. Scheduling Controlled |Taints Taints communicate node conditions • Key – condition category • Value – specific condition • Operator – value wildcard • Equal – value equality • Exists – key existence • Effect • NoSchedule – filter at scheduling time • PreferNoSchedule – prioritize at scheduling time • NoExecute – filter at scheduling time, evict if executing • TolerationSeconds – time to tolerate “NoExecute” taint kind: Pod spec: tolerations: - key: <taint key> value: <taint value> operator: <match operator> effect: <taint effect> tolerationSeconds: 60 @olgch; @kublr
- 34. Scheduling Controlled |Affinity • Node affinity • Inter-pod affinity • Inter-pod anti-affinity kind: Pod spec: affinity: nodeAffinity: { ... } podAffinity: { ... } podAntiAffinity: { ... } @olgch; @kublr
- 35. Scheduling Controlled |Node Affinity Scope • Preferred during scheduling, ignored during execution • Required during scheduling, ignored during execution kind: Pod spec: affinity: nodeAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 10 preference: { <node selector term> } - ... requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - { <node selector term> } - ... v @olgch; @kublr
- 36. Interlude | NodeSelector vs Selector Term ... nodeSelector: <label 1 key>: <label 1 value> ... ... <node selector term>: matchExpressions: - key: <label key> operator: In | NotIn | Exists | DoesNotExist | Gt | Lt values: - <label value 1> ... ... @olgch; @kublr
- 37. Scheduling Controlled |Inter-pod Affinity Scope • Preferred during scheduling, ignored during execution • Required during scheduling, ignored during execution kind: Pod spec: affinity: podAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 10 podAffinityTerm: { <pod affinity term> } - ... requiredDuringSchedulingIgnoredDuringExecution: - { <pod affinity term> } - ... @olgch; @kublr
- 38. Scheduling Controlled |Inter-pod Anti-affinity Scope • Preferred during scheduling, ignored during execution • Required during scheduling, ignored during execution kind: Pod spec: affinity: podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 10 podAffinityTerm: { <pod affinity term> } - ... requiredDuringSchedulingIgnoredDuringExecution: - { <pod affinity term> } - ... @olgch; @kublr
- 39. Scheduling Controlled |Pod Affinity Terms • topologyKey – nodes’ label key defining co-location • labelSelector and namespaces – select group of pods <pod affinity term>: topologyKey: <topology label key> namespaces: [ <namespace>, ... ] labelSelector: matchLabels: <label key>: <label value> ... matchExpressions: - key: <label key> operator: In | NotIn | Exists | DoesNotExist values: [ <value 1>, ... ] ... @olgch; @kublr
- 40. Scheduling Controlled |Affinity Example affinity: topologyKey: tier labelSelector: matchLabels: group: a Node 1 tier: a Pod B group: a Node 3 tier: b tier: a Node 4 tier: b tier: b Pod B group: a Node 1 tier: a @olgch; @kublr
- 41. Scheduling Controlled |Scheduler Configuration • Algorithm Provider • Scheduling Policies and Profiles (alpha) • Scheduler WebHook @olgch; @kublr
- 42. Default Scheduler |Algorithm Provider kube-scheduler --scheduler-name=default-scheduler --algorithm-provider=DefaultProvider --algorithm-provider=ClusterAutoscalerProvider @olgch; @kublr
- 43. Default Scheduler |Custom Policy Config kube-scheduler --scheduler-name=default-scheduler --policy-config-file=<file> --use-legacy-policy-config=<true|false> --policy-configmap=<config map name> --policy-configmap-namespace=<config map ns> @olgch; @kublr
- 44. Default Scheduler |Custom Policy Config { "kind" : "Policy", "apiVersion" : "v1", "predicates" : [ {"name" : "PodFitsHostPorts"}, ... {"name" : "HostName"} ], "priorities" : [ {"name" : "LeastRequestedPriority", "weight" : 1}, ... {"name" : "EqualPriority", "weight" : 1} ], "hardPodAffinitySymmetricWeight" : 10, "alwaysCheckAllPredicates" : false } @olgch; @kublr
- 45. Default Scheduler |Scheduler WebHook { "kind" : "Policy", "apiVersion" : "v1", "predicates" : [...], "priorities" : [...], "extenders" : [{ "urlPrefix": "http://127.0.0.1:12346/scheduler", "filterVerb": "filter", "bindVerb": "bind", "prioritizeVerb": "prioritize", "weight": 5, "enableHttps": false, "nodeCacheCapable": false }], "hardPodAffinitySymmetricWeight" : 10, "alwaysCheckAllPredicates" : false } @olgch; @kublr
- 46. Default Scheduler |Scheduler WebHook func fiter(pod, nodes) api.NodeList func prioritize(pod, nodes) HostPriorityList func bind(pod, node) @olgch; @kublr
- 47. Scheduling Controlled |Multiple Schedulers kind: Pod Metadata: name: pod2 spec: schedulerName: my-scheduler kind: Pod Metadata: name: pod1 spec: ... @olgch; @kublr
- 48. Scheduling Controlled |Custom Scheduler Naive implementation • In an infinite loop: • Get list of Nodes: /api/v1/nodes • Get list of Pods: /api/v1/pods • Select Pods with status.phase == Pending and spec.schedulerName == our-name • For each pod: • Calculate target Node • Create a new Binding object: POST /api/v1/bindings apiVersion: v1 kind: Binding Metadata: namespace: default name: pod1 target: apiVersion: v1 kind: Node name: node1 @olgch; @kublr
- 49. Scheduling Controlled |Custom Scheduler Better implementation • Watch Pods: /api/v1/pods • On each Pod event: • Process if the Pod with status.phase == Pending and spec.schedulerName == our-name • Get list of Nodes: /api/v1/nodes • Calculate target Node • Create a new Binding object: POST /api/v1/bindings apiVersion: v1 kind: Binding Metadata: namespace: default name: pod1 target: apiVersion: v1 kind: Node name: node1 @olgch; @kublr
- 50. Scheduling Controlled |Custom Scheduler Even better implementation • Watch Nodes: /api/v1/nodes • On each Node event: • Update Node cache • Watch Pods: /api/v1/pods • On each Pod event: • Process if the Pod with status.phase == Pending and spec.schedulerName == our-name • Calculate target Node • Create a new Binding object: POST /api/v1/bindings apiVersion: v1 kind: Binding Metadata: namespace: default name: pod1 target: apiVersion: v1 kind: Node name: node1 @olgch; @kublr
- 51. Use Case |Distributed Pods apiVersion: v1 kind: Pod metadata: name: db-replica-3 labels: component: db spec: affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - topologyKey: kubernetes.io/hostname labelSelector: matchExpressions: - key: component operator: In values: [ "db" ] Node 2 db-replica-2 Node 1 Node 3 db-replica-1 db-replica-3 @olgch; @kublr
- 52. Use Case |Co-located Pods apiVersion: v1 kind: Pod metadata: name: app-replica-1 labels: component: web spec: affinity: podAffinity: requiredDuringSchedulingIgnoredDuringExecution: - topologyKey: kubernetes.io/hostname labelSelector: matchExpressions: - key: component operator: In values: [ "db" ] Node 2 db-replica-2 Node 1 Node 3 db-replica-1 app-replica-1 @olgch; @kublr
- 53. Use Case |Reliable Service on Spot Nodes • “fixed” node group Expensive, more reliable, fixed number Tagged with label nodeGroup: fixed • “spot” node group Inexpensive, unreliable, auto-scaled Tagged with label nodeGroup: spot • Scheduling rules: • At least two pods on “fixed” nodes • All other pods favor “spot” nodes • Custom scheduler or multiple Deployments @olgch; @kublr
- 54. Scheduling | Dosand Don’ts DO • Prefer scheduling based on resources and pod affinity to node constraints and affinity • Specify resource requests • Keep requests == limits • Especially for non-elastic resources • Memory is non-elastic! • Safeguard against missing resource specs • Namespace default limits • Admission controllers • Plan architecture of localized volumes (EBS, local) DON’T • ... assign pod to nodes directly • ... use node-affinity or node constraints • ... use pods with no resource requests @olgch; @kublr
- 55. Scheduling | KeyTakeaways • Scheduling filters and priorities • Resource requests and availability • Inter-pod affinity/anti-affinity • Volumes localization (AZ) • Node labels and selectors • Node affinity/anti-affinity • Node taints and tolerations • Scheduler(s) tweaking and customization @olgch; @kublr
- 56. Next steps • Podpriority, preemption, and eviction • Pod Overhead • Scheduler Profiles • Scheduler performance considerations • Admission Controllers and dynamic admission control • Dynamic policies and OPA @olgch; @kublr
- 57.
- 58.
- 59. Oleg Chunikhin CTO oleg@kublr.com @olgch Kublr |kublr.com @kublr Signup for our newsletter at kublr.com
Editor's Notes
- #3 “If you like something you hear today, please tweet at me @olgch”
- #6 I will spend a few minutes reintroducing docker and kubernetes architecture concepts… before we dig into kubernetes scheduling. Talking about scheduling, I’ll try to explain capabilities, … controls available to cluster users and administrators, … and extension points We’ll also look at a couple of examples and… Some recommendations
- #7 Registering nodes in the wizard Appointment of pods on the nodes The address allocation is submitted (from the pool of addresses of the overlay network allocated to the node at registration) Joint launch of containers in the pod Sharing the address space of a dataport and data volumes with containers The overall life cycle of the pod and its container The life cycle of the pod is very simple - moving and changing is not allowed, you must be re-created
- #8 Master API maintains the general picture – vision of desired and current known state Master relies on other components – controllers, kubelet – to update current known state User modifies to-be state and reads current state Controllers “clarify” to-be state Kubelet perform actions to achieve to-be state, and reports current state Scheduler is just one of the controllers, responsible for assigning unassigned pods to specific nodes
- #9 First there was nothing
- #10 Master API maintains the general picture User modifies to-be state and reads current state Controllers “clarify” to-be state Kubelet perform actions to achieve to-be state, and reports current state Scheduler is just one of the controllers, responsible for assigning unassigned pods to specific nodes
- #11 Master API maintains the general picture User modifies to-be state and reads current state Controllers “clarify” to-be state Kubelet perform actions to achieve to-be state, and reports current state Scheduler is just one of the controllers, responsible for assigning unassigned pods to specific nodes
- #12 Master API maintains the general picture User modifies to-be state and reads current state Controllers “clarify” to-be state Kubelet perform actions to achieve to-be state, and reports current state Scheduler is just one of the controllers, responsible for assigning unassigned pods to specific nodes
- #13 Master API maintains the general picture User modifies to-be state and reads current state Controllers “clarify” to-be state Kubelet perform actions to achieve to-be state, and reports current state Scheduler is just one of the controllers, responsible for assigning unassigned pods to specific nodes
- #14 Master API maintains the general picture User modifies to-be state and reads current state Controllers “clarify” to-be state Kubelet perform actions to achieve to-be state, and reports current state Scheduler is just one of the controllers, responsible for assigning unassigned pods to specific nodes
- #15 Master API maintains the general picture User modifies to-be state and reads current state Controllers “clarify” to-be state Kubelet perform actions to achieve to-be state, and reports current state Scheduler is just one of the controllers, responsible for assigning unassigned pods to specific nodes
- #16 Master API maintains the general picture User modifies to-be state and reads current state Controllers “clarify” to-be state Kubelet perform actions to achieve to-be state, and reports current state Scheduler is just one of the controllers, responsible for assigning unassigned pods to specific nodes
- #17 Master API maintains the general picture User modifies to-be state and reads current state Controllers “clarify” to-be state Kubelet perform actions to achieve to-be state, and reports current state Scheduler is just one of the controllers, responsible for assigning unassigned pods to specific nodes
- #18 Master API maintains the general picture User modifies to-be state and reads current state Controllers “clarify” to-be state Kubelet perform actions to achieve to-be state, and reports current state Scheduler is just one of the controllers, responsible for assigning unassigned pods to specific nodes
- #19 Master API maintains the general picture User modifies to-be state and reads current state Controllers “clarify” to-be state Kubelet perform actions to achieve to-be state, and reports current state Scheduler is just one of the controllers, responsible for assigning unassigned pods to specific nodes
- #21 Pod requests new volumes, can they be created in a zone where the can be attached to the node? If requested volumes already exist, can they be attached to the node? If the volumes are already attached/mounted, can they be mounted to this node? Any other user-specified constraints?
- #27 This most often happens in AWS, where EBS can only be attached to instances in the same AZ where EBS is located
- #40 This pod should be co-located (affinity) or not co-located (anti-affinity) with the pods matching the labelSelector in the specified namespaces, where co-located is defined as running on a node whose value of the label with key topologyKey matches that of any node on which any of the selected pods is running. Empty topologyKey: For PreferredDuringScheduling pod anti-affinity, empty topologyKey is interpreted as "all topologies" ("all topologies" here means all the topologyKeys indicated by scheduler command-line argument --failure-domains); For affinity and for RequiredDuringScheduling pod anti-affinity, empty topologyKey is not allowed.
- #41 This pod should be co-located (affinity) or not co-located (anti-affinity) with the pods matching the labelSelector in the specified namespaces, where co-located is defined as running on a node whose value of the label with key topologyKey matches that of any node on which any of the selected pods is running. Empty topologyKey: For PreferredDuringScheduling pod anti-affinity, empty topologyKey is interpreted as "all topologies" ("all topologies" here means all the topologyKeys indicated by scheduler command-line argument --failure-domains); For affinity and for RequiredDuringScheduling pod anti-affinity, empty topologyKey is not allowed.
- #57 Unified application delivery and ops platform wanted: monitoring, logs, security, multiple env, ... Where the project comes from Company overview Kubernetes as a solution – standardized delivery platform Kubernetes is great for managing containers, but who manages Kubernetes? How to streamline monitoring and collection of logs with multiple Kubernetes clusters?
- #58 Unified application delivery and ops platform wanted: monitoring, logs, security, multiple env, ... Where the project comes from Company overview Kubernetes as a solution – standardized delivery platform Kubernetes is great for managing containers, but who manages Kubernetes? How to streamline monitoring and collection of logs with multiple Kubernetes clusters?