Kubernetes traits	The control plane components are the main control point for the cluster. Control plane components include: - The cloud controller. - The scheduler. - The API server.
Kubernetes autoscaling	Control plane components can be run on any machine in the cluster. However, for high availability, control plane components are usually run on a dedicated group of hosts, and user containers are scheduled on other hosts.
ReplicaSets and Deployments	For redundancy and resilience, you will often want replicas of pods rather than just singletons. A ReplicaSet ensures that a specific number of pod replicas are running at any given time. You can create and manage ReplicaSets yourself, but it's more common for ReplicaSets to be managed by deployment.
Services	It's a logical collection of pods and a means to access them. The service is continually updated with the set of pods available, eliminating the need for pods to keep track of their pods themselves.
Kubectl	- Kubectrl is a command-line interface for communicating with the Kubernetes API Server for a given cluster. - Kubectl controls the Kubernetes cluster manager. - Kubectl is a multi-purpose tool for container orchestration and management. - Kubectl provides commands to create resources, view detailed information about the cluster and resources, and access troubleshooting tools. - Kubectls commands are used to rollout, scale, and autoscale resources. - Kubectl is a vital tool in orchestrating the services within your cluster.
Dashboard	Kubernetes also has a web-based user interface called Dashboard. - Deploye containerized applications to a Kubernetes cluster. - Troubleshoot your containerized application. - Manage the cluster along with its attendant resources. - Get an overview of applications running on your cluster. View information on the state of a Kubernetes resource in the cluster. - View any errors that may have ocurred.
What is the basic unit of deployment Kubernetes?	A. Containers B. Pods* C. tasks D. Services
What is the basic unit of deployment Kubernetes?	A. Containers B. Pods* C. tasks D. Services
What is a Kubernetes service?	A. A logical collection of pods and a means to access them* B. A logical collection of pods and a means to schedule them. C. A physical set of nodes that host-related pods. D. None of the above.
Inside EKS	It's a highly available single-tenant infrastructure that makes use of native AWS components. Control plane components run in their own virtual private cloud (VPC), which is frontend by a network load balancer. The services and etcd are in separate auto-scaling groups. The Amazon EKS control plane will scale horizontally.
What form of Kubernetes does EKS support?
Managed Node Groups	By default, you manage the worker nodes in the cluster and the applications that run on them. You also manage how pods are placed on your worker nodes, which is something we will explore in more detail later. This gives you a lot of control over exactly how your data plane behaves, but it can also be a lot of management. EKS can help.
AWS Fargate	Fargate provides on-demand, right-sized compute capacity. With Fargate, you no longer have to provision, scale or manage EC2 instances for your EKS cluster. This shifts the focus away from worker nodes to your pods themselves.
Fargate profiles	You can be also flexible: maybe some of your pods will run great on Fargate but other pods have specific requirements and you need more control over pod placement on your worker nodes.
The PodSpec	Here is a basic example of a Podspec to define a pod that has a single Ubuntu container. A PodSpec includes the pod name, the containers, and the volumes that will be created for the pod.
Pod placement	the scheduler looks at the resources required by your pods and uses that information to influence the scheduling decision. So let's take a look how you can define the resource requirements for your pods.
Resource requirements and constraints
Taints and Tolerations	Node affinity is a property of Pods that attracts them to a set of nodes (either as a preference or a hard requirement). Taints are the opposite -- they allow a node to repel a set of pods. Tolerations are applied to pods, and allow (but do not require) the pods to schedule onto nodes with matching taints. Taints and tolerations work together to ensure that pods are not scheduled onto inappropriate nodes. One or more taints are applied to a node; this marks that the node should not accept any pods that do not tolerate the taints.
Affinity and anti-affinity	nodeSelector provides a very simple way to constrain pods to nodes with particular labels. The affinity/anti-affinity feature greatly extends the types of constraints you can express.
Auto scaling in EKS	Auto scaling can also be configured for applications running in the data plane. The Horizontal Pod Autoscaler (HPA) and Kubernetes Metrics Server are supported by EKS.
Which components are always managed by EKS?	The Kubernetes control plane
Docker communication	By default, Docker uses a private host-level virtual bridge with an address range allocated by NAT from one of the standard private blocks. These days, Docker supports more networking models, but he above bridge model has been the default mode historically and many other orchestration tools rely on it.
Ingress with Dynamic port allocation	To address this problem, Docker users dynamic port allocation where a random port from the host IP address is mapped to a container IP:port pair.
Inter-host communication with DPA	Any inter-host communication must also go through the load balancer because the containers themselves are unaware of the external IP address by which they can be accessed. In this example, the target container's IP address is hidden from containers on other hosts because of the Network Address Translation (NAT) being performed by the Docker bridge.
EKS Communication	Amazon EKS supports native VPC networking with the Amazon VPC Container Network Interface (CNI) plugin for Kubernetes. This plugin assigns a private IPv4 or IPv6 address from your VPC to each pod. The plugin is an open-source project that is maintained on GitHub.
Incorporating Services	A service provides a constant IP address and port as an entry point to a group of pods. Each service has an IP address and port that will never change for as long as the service exists. Internal or external clients can reach out to your application running in a group of pods by connecting to the service IP and port. this is an example of a ClusterIP service, which is the default type.
Inside Service	The most important field in the spec is "selector", which pods will serve as endpoints for this service. In this case, any pods with the label app=MyApp will be part of this service. In this example, we're also exposing two pots -- 80 and 443 -- that map to container ports 9376 and 9377, respectively.
NodePort service example	This example shows a NodePort service, which is almost the same as a ClusterIP service, except that it will also open a port on each node, allowing access to the service not only from within the cluster (using the ClusterIP) but also from external parties connecting directly to the node on the nodePort.
LoadBalancer service example
ExternalName service example
Ingress controller example	A Kubernetes ingress is an API object that allows ou manage external or internal HTTP or HTTPS access to Kubernetes services running in a cluster.
EmptyDir volume example	Volumes are configured in the PodSpec. You can also state where to mount these volumes into containers. This is an example of an emptyDir volume. It's created when a pod is assigned to a node, and it exists as long as that pod is running on that node.