rc-0.1

chapter/01_introduction.tex

@@ -13,16 +13,19 @@ \section{Motivation and goal}
 To simplify the complexity of managing compute resources, as well as deploying and scaling an application, so-called container orchestration systems were built with the advent of Docker.
 One of these systems, which has found great acceptance in the market, is Kubernetes.
 It follows the cloud-native\footnote{https://github.com/cncf/toc/blob/main/DEFINITION.md} approach, which is due to a constantly changing environment.
-In the following, the terms CLuster refers to a Kubernetes cluster and nodes are the number of servers that are grouped together in a cluster.
-In the event of a crash or the removal or addition of a node, Kubernetes ensures that the application can continue to run.
+In the following, the terms Cluster refers to a Kubernetes cluster and nodes are the number of servers that are grouped together in a cluster.
+In Production environment it is recommended to run Kubernetes in an High Available setup.
+%HA explain?
+That is, there is a failover mechanism in case the master node crashes and ensures High Availabilities.
+In the event of a crash, or the number of node changes, Kubernetes ensures that the application can continue to run.
 With Kubernetes, it is therefore comparatively easy to distribute an application across multiple servers and ensure scalability.
 \\
 %Load Balancers in cloud native
 With the potentially ever-changing number of nodes, the question of load balancing also arises.
 Typically, load balancers are used to serve as entry points and distribute traffic across multiple servers.
 In a cloud-native environment, the configuration of a load balancer must also adapt to the constantly changing environment.
 \\
-Kubernetes provides a basis for dynamically creating/deleting and adapting an external load balancer.
+Kubernetes provides a basis for dynamically create, delete and adapting an external load balancer.
 However, it does not offer an out-of-the-box implementation of load balancers for clusters.
 The implementations of load balancer is only available at various IaaS platforms (GCP, AWS, Azure).
 This means for bare-metal clusters a manual integration for a load balancer service.
@@ -34,29 +37,15 @@ \section{Motivation and goal}
 There are several solutions for implementing load balancers, but these are designed for one cluster and usually require their own network setup.
 The Project KubeLB\footnote{https://github.com/kubermatic/kubelb} aims to provide a load balancer integration for multiple clusters and takes the advantages of kubernetes itself.
 
-\newpage
-
 \section{Structure of this work}
 Following the introduction, the basics in the area of cloud-native and Kubernetes, as well as load balancing are first laid.
-
 In the following chapter, the function of load balancers and the included network components and options with respect to Kubernetes will be discussed in more detail.
-
 Chapter four discusses concepts and options within Kubernetes for extending functionality.
-
 Subsequently, chapter five analyzes the concepts and transferability of the Kubermatic Kubernetes Platform and presents the KubeLB proposal.
-
 In the sixth chapter, responsibility is distributed among subsystems, and a mechanism for communication between the individual components is described.
 The interaction of the components is then modeled based on the underlying features of Layer 4 and Layer 7 load balancing.
 Finally, the choice of the load balancer used is discussed.
-
 Chapter seven describes the implementation of the components developed in chapter six and their integration into Kubernetes.
-
 Following the implementation, software tests will be described.
-
 The final chapter of the thesis draws a conclusion with regard to the technologies used, and the architectural design decisions.
-
 This is followed in the last chapter by an outlook on further features that have not yet been implemented.
-
-
-%\section{Cloud Native}
-%Todo: add section

chapter/02_basics.tex

@@ -3,17 +3,16 @@ \chapter{Basics}\label{basics}
 This chapter provides a basic understanding of load balancing and Kubernetes.
 The focus is mainly on the parts that are needed for the KubeLB Project.
 It is not going into detail of everything and won't cover all load balancing features, algorithms and Kubernetes possibilities.
-The load balancing part focuses on features that are commonly used inside the cloud environment, especially Kubernetes and is not covering other scenarios.
+The load balancing part focuses on features that are commonly used inside a cloud environment, especially Kubernetes and is not covering other scenarios.
 
 \section{Load Balancing}
 
-In simple, a load balancer is a software or hardware device which distributes incoming traffic among a set of servers.
+A load balancer is a software or hardware device which distributes traffic among a set of servers.
 They usually serve as an entrypoint and offer different features in a cloud environment.
 \\
-The most obvious feature is to distribute traffic to multiple servers.
-Load balancers offer a variety of algorithms for how traffic is distributed among endpoints.~\cite{ALLEN-LOAD-BALANCING}
+Load balancers offer a variety of algorithms for how traffic is distributed among endpoints.
 
-\begin{itemize}
+\begin{itemize}\label{item:lb-algorithms}
     \item \textit{Random Load Balancing} \\
     As the name suggests, traffic is distributed randomly to the endpoints.
     This can result in one endpoint receiving a lot of traffic, and others receiving very little traffic.
@@ -27,11 +26,9 @@ \section{Load Balancing}
     This highly depends on the load balancer implementation.
 \end{itemize}
 
-The second feature is to dynamically change the configuration of your load balancer.
-In a production environment it is important not to interrupt your services or even dropping connections by restarting some components, especially for critical infrastructure like a load balancer.
-This is useful in terms of auto scaling with a dynamic number of endpoints, which may is based upon the current server load.
+Choosing the best algorithm is not always trivial and depends on the application.~\cite{ALLEN-LOAD-BALANCING}
 \\
-The third one is to provide a failover for ``High Available`` setups.
+For high available setups a load balancer can provide a failover mechanism.
 This requires a health check mechanism, like TCP or HTTP probes.
 These probes are used to determine the endpoints healthiness and mark an endpoint as unhealthy if one or more probes fail.
 When an endpoint becomes unhealthy, the load balancer stops forwarding traffic to it.
@@ -44,15 +41,15 @@ \section{Load Balancing}
 \\
 A layer 7 load balancer takes place on the Application layer, using protocols such as HTTP and SMTP.
 At this level the load balancer does have more information and can perform smarter decisions.
-In terms of HTTP this means you can take routing decisions based upon HTTP Headers.
+In terms of HTTP this means it can take routing decisions based upon HTTP Headers.
 TLS termination is also handled by Layer 7 load balancers.~\cite{NICHOLSON-LOAD-BALANCING}
 
 \section{Kubernetes}
-
 ``Kubernetes is an open-source container-orchestration system for automating computer application deployment, scaling, and management``\cite{Kubernetes}.
-A Cluster contains a so called control-plane which is responsible for the cluster state.
-The control-plane is a set of controllers which observe different objects of the cluster, react to changes and trie to bring the cluster into it's desired state.
-\autoref{fig:kubernetes} gives you an overview about the Kubernetes Components
+Kubernetes clusters contain a so called control-plane which is responsible for the cluster state.
+The control-plane is a set of controllers which observe different objects of the cluster, react to change and trie to bring the cluster into it's desired state.
+It also contains the information about the current cluster status.
+\autoref{fig:kubernetes} gives an overview about the Kubernetes components.
 
 \begin{figure}[H]
     \centering
@@ -66,12 +63,13 @@ \section{Kubernetes}
 The kubelet daemon is responsible for the node status, and the containers that are deployed to it.
 It serves like an agent to the cluster and communicates with the api server.
 Together with kubelet, the host needs an application that implements the Container Runtime Interface.\footnote{CRI: the Container Runtime Interface\footcite{CRI}}
-This is needed to run the actual container.
+This is required to run the actual container.
 \\
 Besides kubelet, kube-proxy is responsible for the networking part like routing and exposing services.
 This is important for services to communicate inside the cluster.
 A more detailed overview can be found in \autoref{sec:kubeproxy}.\cite{KUBERNETES-COMPONENTS}
 \\
+\newpage
 
 Kubernetes offers a various set of building blocks ("primitives"), which describe different parts in the cluster to deploy an Application.
 Each object shares the same basic data structure.
@@ -91,28 +89,28 @@ \section{Kubernetes}
 Some objects also have a status field that describes the current state.~\cite{KUBERNETES-OBJECTS}
 
 \subsection{Pods}
-The first basic one is a ``Pod`` that is a group of one or more containers.
-The containers share storage, network, and runtime specifications.
-\\
+A pod is a Kubernetes object, that describes a group of one or more containers.
 Kubernetes manages pods instead of containers directly, so a pod is a wrapper around one or more containers.
+It contains information of the docker image, volumes, ports and more.
+An example of the information of a pod can be fond at \textit{spec.template} in \autoref{fig:deployment}.
+The containers inside a pod share storage, network, and runtime specifications.
 \\
 There are applications where two containers are tightly coupled together.
 Then it can make sense to deploy these containers together in one pod.
 This ensures that the containers are deployed on the same node and have the same resources at their disposal, which has a positive effect on performance.
 \\
-It holds information of the docker image, volumes, ports and more.
-A Pod is not created directly, instead it is described inside a Deployment, StatefulSet or DaemonSet.~\cite{KUBERNETES-POD}
+A pod is not created directly, instead it is described inside a deployment, StatefulSet or DaemonSet.~\cite{KUBERNETES-POD}
 
 \subsection{Deployment}\label{subsec:deployment}
 
-A Deployment takes track of the current state, make changes to an existing Pods in a controlled rate, scaling and more.
+A deployment takes track of the current state, make changes to an existing pods in a controlled rate, scaling and more.
 It is widely used to deploy applications in a general purpose way.
-The ``spec.template`` describes the actual pod created by the deployment, with its metadata and Pod spec.
+The field \textit{spec.template} describes the actual pod created by the deployment, with its metadata and pod spec.
 The \autoref{fig:deployment} illustrates an example deployment, with two containers and ports, inside a pod.
-Deployments have a selector which tells the controller which Pod is controlled by this deployment.
-The label ``app: foo-bar``is used as the selector and is also set inside the template, so all Pods created by this template are referenced to the deployment.
+deployments have a selector which tells the controller which pod is controlled by this deployment.
+The \textit{app: foo-bar} label is used as a selector and is also set within the template so that all pods created with this template are referenced to the deployment.
 If applied, Kubernetes will create one pod, according to the replicas field, with two containers.
-The containers use the same image, but with different environment variables and Ports.
+The containers use the same image, but with different environment variables and ports.
 Those control what the HTTP service of the image will return and on what port it listens.~\cite{KUBERNETES-DEPLOYMENT}
 
 \begin{figure}[H]
@@ -124,10 +122,10 @@ \subsection{Deployment}\label{subsec:deployment}
 
 
 \subsection{Service}\label{subsec:service}
-To expose an application and make it accessible for others, the ``Service`` object is used.
+To expose an application and make it accessible for others, the service object is used.
 This is an abstraction of the networking layer and decides how to expose an application.
-Services are used to open and map one or multiple ports of a Pod.
-The actual Pod where the service applies to, is chosen by a selector.
+services are used to open and map one or multiple ports of a pod.
+The actual pod where the service applies to, is chosen by a selector.
 This is important so that the controller knows to which pods the traffic is routed.
 To keep track of which endpoints are currently available, the controller automatically creates an endpoint object.
 
@@ -138,16 +136,16 @@ \subsection{Service}\label{subsec:service}
     \label{fig:endpoints}
 \end{figure}
 
-As \autoref{fig:endpoints} shows, an endpoint holds a list of IP addresses (in this case its just one as only one Pod is deployed), as well as the associated ports.
+As \autoref{fig:endpoints} shows, an endpoint holds a list of IP addresses (in this case its just one as only one pod is deployed), as well as the associated ports.
 In addition, the endpoints object is filled with further meta information by the controller.
-Kubernetes scans for Pods inside the cluster that match the given selector and updates the corresponding Endpoint object.
+Kubernetes scans for pods inside the cluster that match the given selector and updates the corresponding endpoint.
 For a service without a selector, no associated endpoint is created and must be created otherwise.
 TCP, UDP and SCTP are supported as protocols, TCP is the default.
 
 \autoref{fig:service} shows an example service for the previous foo-bar deployment.
 It exposes two ports one named foo at Port 8080, and bar at Port 8081.
-Target port describes the Port of the actually Pod and could be omitted because it is the same value as port.
-The selector is ``app: foo-bar``, which was assigned to the pods as labels in the previous deployment.
+Target port describes the Port of the actual pod and could be omitted because it is the same value as port, which describes the port to expose by the service.
+The selector is \textit{app: foo-bar}, which was assigned to the pods as labels in the previous deployment.
 
 \begin{figure}[H]
     \centering
@@ -156,7 +154,6 @@ \subsection{Service}\label{subsec:service}
     \label{fig:service}
 \end{figure}
 
-
 It offers different types of exposing an application.
 Type ClusterIp is the default and exposes the application only to other services inside the cluster.
 These services can be addressed via an internal DNS.
@@ -167,13 +164,10 @@ \subsection{Service}\label{subsec:service}
 Thus, the service is externally accessible on all nodes of the cluster via the allocated port.
 \\
 Type LoadBalancer does the same as node port with the addition of an external implementation to dynamically create a load balancer and point it to the opened node ports.
-This is not implemented by default and requires some extra setup for the cluster, what is explained in more detail in \autoref{sec:ExternalLoadBalancer}.
-\\
-A service has a corresponding ``Endpoints`` object.
-Inside the cluster these are created automatically, via a selector inside the service object, that points to pod.~\cite{KUBERNETES-SERVICE}
-\subsection{Ingress}\label{subsec:ingress}
+This is not implemented by default and requires some extra setup for the cluster, what is explained in more detail in \autoref{sec:ExternalLoadBalancer}.~\cite{KUBERNETES-SERVICE}
 
-The Ingress Object is built as an addition to services and offers load balancing, TLS Termination or name-based virtual hosting.
+\subsection{Ingress}\label{subsec:ingress}
+The ingress is built as an addition to services and offers load balancing, TLS Termination or name-based virtual hosting.
 Typically, it exposes only HTTP/HTTPS, other applications should make use of the service type NodePort or LoadBalancer.
 It provides a number of configurable rules that decide to which backend the traffic is routed.
 Thus, applications do not have to be directly exposed via a service, they only need to be internal accessible via ClusterIP.~\cite{KUBERNETES-INGRESS}