Advanced Scheduling in Kubernetes

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?