Same as last week, keep working on the tutorial of Kubernetes Fundamentals.

Services

Service in kubernetes is a very important object. They are agents which connect Pods together, or provide access outside of the cluster.
The common types of service are ClusterIp, NodePort and LoadBalancer.

Here's the official explanation.

ClusterIp

The ClusterIP service type is the default, and only provides access internally (except if manually creating an external endpoint). The range of ClusterIP used is defined via an API server startup option.

NodePort

The NodePort type is great for debugging, or when a static IP address is necessary, such as opening a particular address through a firewall. The NodePort range is defined in the cluster configuration.

LoadBalancer

The LoadBalancer service was created to pass requests to a cloud provider like GKE or AWS. Private cloud solutions also may implement this service type if there is a cloud provider plugin, such as with CloudStack and OpenStack. Even without a cloud provider, the address is made available to public traffic, and packets are spread among the Pods in the deployment automatically.

And the last one ExternalName, which is new to me. 💡

A newer service is ExternalName, which is a bit different. It has no selectors, nor does it define ports or endpoints. It allows the return of an alias to an external service. The redirection happens at the DNS level, not via a proxy or forward. This object can be useful for services not yet brought into the Kubernetes cluster. A simple change of the type in the future would redirect traffic to the internal objects.

In short, externalName can point to external DNS CNAME, not like the other service will point to a certain pod.

Volumes and Data

There's one project call Rock mentioned in this section.
Rock can be seem as a storage orchestrator provides a common framework across all of the storage solutions, like ceph, nfs, Cassandra, etc.

Rook turns distributed storage systems into self-managing, self-scaling, self-healing storage services. It automates the tasks of a storage administrator

Scheduling

Scheduling is the key of kubernetes.
There's a lot of strategy that you can use when scheduling pods in kubernetes.
One is call pod affinity, and there are several kind of pod affinity rules.

1. requiredDuringSchedulingIgnoredDuringExecution
   means that the Pod will not be scheduled on a node unless the following operator is true. If the operator changes to become false in the future, the Pod will continue to run. This could be seen as a hard rule.

2. preferredDuringSchedulingIgnoredDuringExecution

preferredDuringSchedulingIgnoredDuringExecution will choose a node with the desired setting before those without. If no properly-labeled nodes are available, the Pod will execute anyway.

1. podAffinity / podAntiAffinity
   Which will keep pods together or keep them on different nodes.

2. topologyKey
   This rule is new to me.
   The topologyKey allows a general grouping of Pod deployments. Affinity (or the inverse anti-affinity) will try to run on nodes with the declared topology key and running Pods with a particular label. The topologyKey could be any legal key, with some important considerations.
   In short, we can use topologyKey to scheduler our pod based on the topoloy in a rack or a region's view.

💡To check the scheduler event on the current k8s cluster, you can use.

kubectl get events

Logging and Troubleshooting

Ephemeral Containers
Ephemeral container is a new alpha feature in v1.16.
Allowing user can attach a container to a existing pod.
You may be able to use the kubectl attach command to join an existing process within the container. This can be helpful instead of kubectl exec, which executes a new process. The functionality of the attached process depends entirely on what you are attaching to.

kubectl debug buggypod --image debian --attach

Cluster Start Sequence
If you built the cluster using kubeadm, then the sequence will begins with systemd.
kubelet will create any YAML inside the staticPodPath.
So this is also where that api-server, kube-scheduler, kube-controller YAMLs stored.
In most case your staticPodPath will be /etc/kubernetes/manifests
So you can see your api-server, kube-scheduler or other default service's YAMLs here.