Kubernetes Terminology in 8 minutes

cubectl is a command line tool that allows us to talk to the kubernetes api server cube ctl is configured with a cube config file the address and authentication detail is defined in the cube config this tells cubectl where the api server is and which cluster we can talk to in our config we can set a context which points to our dev cluster uat cluster or prod cluster the api server takes our instructions and makes it happen in the cluster the api server runs in the control plane alongside the scheduler and other controllers controllers watch the state of the world and make sure the desired state matches the actual state more about controllers later let's start with the objects we can apply to kubernetes we apply objects as yaml files a pod is a workload that we want to deploy to kubernetes the workload can be any type of compute script code or application a part can also be more than one process a pod has a name it has labels we can also add metadata to the pod called annotations a process in the pod is called a container a part can contain more than one container containers have environment variables ports to receive network traffic resources which define request values of how much cpu and memory the pod needs as well as limits and kubernetes will throttle pods that use more cpu as well as kill pods that go over their memory limit liveliness probes ensure that containers are alive and kubernetes will restart the pod if the probe condition is not met readiness probes are similar but tells kubernetes when the pod is ready to take traffic this is for pods that may need to initialize data or get ready to accept network connections a startup probe is a newer feature they are similar to readiness pros but executed only at the start and designed for slow starting containers with an unpredictable initialization process volume mounts allow us to mount files into specific paths of the container in order to mount a file a volume needs to be defined volumes are a medium of storage attached to a pod volumes can be a folder on the host where the pod is running or a persistent volume more on that later volumes can also be configurations or secrets configurations are defined as config maps config maps allow us to store configurations for pods as files or key value pairs that can be mapped to environment variables a secret is similar we can store files tls certificates or key value pairs that can be mapped to environment variables now there are a number of ways to run pods one way is a cron job a cron job is a way to schedule a pod you can run a pod once a day once a week once a month or at your own custom schedule every time the schedule is triggered a job gets created and a job can run one or more pods if you want to run a pod constantly like a web server a proxy or an application you can use a deployment a deployment has a number of replicas which tells kubernetes how many pods to run concurrently pods are distributed across nodes in the cluster nodes are machines where the containers run as pods nodes can be physical on-prem or virtual cloud machines when pods are created they may move around this is okay for web servers but not for databases or caches this is where stateful sets come in it's similar to a deployment but allows us to pin pods to nodes when a pod restarts it gets recreated on the same node to ensure its storage is reattached to the same pod stateful sets also have replicas and pod information as described earlier dateful sets provide volume claim templates that allows us to dynamically provision storage for a new pod when it scales up using a storage class storage classes abstract storage that a cluster offers a cluster can offer various amount of storage like azure file share aws block storage gce disk nfs network share local file storage and more storage classes are defined at a cluster level so it can be consumed by the platform to consume a storage class in a pod we define a persistent volume a persistent volume indicates its storage class and represents a size of the storage available to the cluster every pod can have its own persistent volume or you can share persistent volumes through persistent volume claims persistent volume claims allow developers to claim storage from a persistent volume without having to provision or interact with the storage itself if we want to ensure that we run a pod on every node we can use something called a daemon set daemon sets has its own scheduling mechanisms to ensure a pod runs on every node this is great for something like monitoring agents on each of the nodes a log collector to collect pod logs from each node or a daemon that provisions node storage for all these ways to deploy pods we may need to enable network communication between pods this is where services come in services allow us to define how to access pods over the network when we define a service we give it a name and we select pods using label selectors we define a service port and map it to a pod container port the pods are then accessible over the service name as a dns plus port the types of services available are cluster ip for private communication load balancer for public communication headless services for each pod to have its own dns without load balancing and node port where the parts can be reached by public ipn port of the node node ports have strict limitations services are very basic for public traffic we often prefer proxies to serve traffic over a url https and route based on domain or url path this is where ingress comes in ingress is a rule set that allows us to define how we want to accept traffic into the cluster without having to configure proxies and route to various services ingressors have rules where we define a host domain a url path and a target service and port this allows us to accept traffic on a single load balancer service and route request to different private services ingress objects are managed by an ingress controller which watches the state of ingresses and updates its core proxy whenever ingresses gets added deleted or updated there are many types of ingress controller implementations like nginx traffic envoy haproxy and more an ingress controller is a controller controllers are pods that run in a controlled loop a controlled loop is a non-terminating loop that regulates the state of a system a controller tracks at least one kubernetes resource type ingress controllers track ingress objects there are other types of controllers we can even build our own all of these are designed for developers who wish to extend kubernetes further now namespaces provide a way to divide cluster resources between users teams and departments it's like a grouping mechanism deploy all your monitoring pods to a monitoring namespace deploy your ingress controllers to its own namespace all the control plane pods are in the cubesystem namespace you could also have a namespace per team or none at all for objects the names should be unique per namespace to give users permissions to namespaces we use rbac roles and role bindings provide permissions to objects in a namespace cluster roles and cluster role bindings provide permissions across all namespaces that is most of the terminology you will need to get started if you like the video be sure to like and subscribe hit the bell check out the links below to other videos and the community page and until next time peace [Music]

Channel: That DevOps Guy

Views: 4,974

Rating: 4.971292 out of 5

Keywords: devops, infrastructure, kubernetes, k8s, cloud, training, course, cloudnative, development, deployment, containers, web, beginners, tutorial, guide

Id: Ero82CCQIGk

Length: 8min 4sec (484 seconds)

Published: Wed May 12 2021