IMO; best way to learn Kube is by:

1. Reading the docs (https://kubernetes.io/docs/home/) 
2. Hands-on with a small cluster

Without knowing what you're attempting to USE k8s for, it's hard to recommend anything very specific. 

Are you using it to schedule massive event-driven workloads where a service mesh is going to be critical?  Are you looking to run a pile of separately namespaced web-apps that need pod security policies well defined to prevent inter-pod-calls? Are you needing to deploy stableSet services with storage? Etc.  

It's been a long tim since I've on-boarded anyone who didn't know k8s better than on-prem nodes these days; so I'm probably too rusty to know how to explain it well.  

Some of this is grossly simplified. Read the docs if you want a detailed understanding; but this should get you going.

At its core: kubernetes is 5 major components:

1. The control plane 
2. Kubelet
3. The container runtime daemon
4. Controllers
5. Manifests 

If you're deploying k3s: then the first three are fundamentally bundled up as part of the "install and join a cluster" steps.  I highly recommend you dive more deeply into these, k3s is great to get started, but once you cross the ~25-50 node range you'll want to start looking at native k8s so you can HA the control plane components and optimize them for your needs. 

The control plain does several things, but at its core it offers an HTTP API with various endpoints that handle various cluster critical actions.  Nodes joining the cluster, for example, POST to the API and if they both pass mutual TLS auth and contain the pre-shared key: succeed and create some ETCD (one of the critical control plane components) entries that detail the node.    The node controller polls these key spaces and once it sees a new node is registered missing some annotations; it issues commands to the kublet process running on the node asking it to perform various setup actions.  Once it gets the various ACK's back from the node, the controller updates the objects in the API to indicate that the node is ready. 

Controllers are easy to think of: they ask the API what keys exist under certain namespace paths in a loop.  Like the node controller, any controller: sees resources, performs some actions, updates the API, and restarts over and over. 

Some controllers have obvious functions: the node controller manages the lifecycle of "node" resources.  Other controllers manage other types of objects.   The deployment controller is one that manages a meta type: deployments.  Deployment resources are made up of OTHER resources (commonly replicaSets, statefulSets, or other types of resources) which each have their own controllers that manage those "lower level" resources. 

Manifests are the definition contained within a resource; ie a deployment manifest gets written to the /namespace/deployments/[deployment-name] endpoint of the API. On writing this manifest, the API assigned it an ID (actually ETCD assigns it an ID at insert time, but I digress) which becomes part of the status element of the manifest in the control plane API. 

As manifests are written, the controllers will eventually poll the API and "notice" the manifest.  Once they do, they will iterate over each and check for the traces that it has been there before: when it sees its own "done" marks, it continues onto the next manifest, while anything new gets handled as expected.    Updates increment the version field (while the controller will update a status field to indicate which version the controller last processed, allowing each controller the ability to watch for change)

K8s is eventual consistency : manifests do not directly trigger actions; the controllers do things based on resource that have been committed to the API.

There's a few other "need to know" things about k8s; again I highly encourage anyone interested to read the manual. Namely a network plugin, a storage provisioner, and an ingress controller are all CRITICAL functionality for basically every k8s cluster that exists; these are each their own entire topic that any advice depends heavily on what you plan to use the cluster for.   Some network plugins are great for highly isolated environments, while others are higher performance and flexibility for lower security high throughput situations.    Storage: if you can keep it out of the cluster you'll have a much better time running workloads; but that's not always practical.    Ingress is critical unless the services are only accessible on a local network (but even then..) 

Best of luck!