commit b154def1a66f6ab8d77d16cb00f5fd37ba7039ac
parent d800e16c9fa249847d98419fafc986ebd5a16ff5
Author: MTRNord <mtrnord1@gmail.com>
Date: Sat, 9 Nov 2024 15:08:24 +0100
Split tex files into chapters
Diffstat:
| M | build.sh | | | 1 | + |
| A | pages/chapter1.tex | | | 44 | ++++++++++++++++++++++++++++++++++++++++++++ |
| A | pages/chapter2.tex | | | 271 | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |
| M | root.tex | | | 308 | ++----------------------------------------------------------------------------- |
| M | style.sty | | | 7 | ++++++- |
5 files changed, 326 insertions(+), 305 deletions(-)
diff --git a/build.sh b/build.sh
@@ -3,6 +3,7 @@
rm -r build
mkdir -p build
cp root.tex build/root.tex
+cp -r pages/ build/pages
cp bibliography.bib build/bibliography.bib
cp style.sty build/style.sty
diff --git a/pages/chapter1.tex b/pages/chapter1.tex
@@ -0,0 +1,43 @@
+Helm is a system for managing \Glspl{k8sResources} and being able to deliver a simple to deploy bundle to administrators using \Gls{k8s} similar to Docker Compose or Ansible.
+
+It is one of the most used packaging systems in the \Gls{k8s} ecosystem and helps to provide a consistent \gls{ux} in the ecosystem.
+
+\section{Helm as a packaging system}
+Helm itself describes itself as \enquote{The package manager for Kubernetes}\cite{helmauthorsHelm}
+This means it's main goal and design is centered around being able to package an application, deal with dependencies and versioning.
+
+As a result of this Helm is a generic way to define an application deployment.
+In doing that it shares similarities with systems like Ansible, nix and other packaging solutions in the Linux world.
+In the typical Docker illustration style the Helm deployment would be a delivery which contains a given set of Containers which are delivered together to build a single big thing.
+
+\section{Helm as a template engine}
+As part of being a package manager for Kubernetes it has to deal with definitions written in pure YAML.
+Therefor it features a powerful template engine which works similar to how Ansible's template engine works.
+
+Under the hood this is archived by using the Go template language\cite{helmauthorsTemplateFunctionsPipelines,thegoauthorsTemplatePackageText} as well as additional go functions provided to the users.
+
+On top of the template language itself it also provides the option to print messages at the end of the installation or upgrade as well as nesting charts, having libraries for charts and using a global value context.
+These are needed to provide consistent helm charts across a company or set of related charts and to ensure a nice \gls{ux} for those deploying said chart.
+
+\section{Features Helm gives us over pure \Glspl{k8sResources}}
+Pure \Glspl{k8sResources} come with multiple downsides over helm or similar packaging systems for \Gls{k8s}.
+
+\Gls{k8s} brings no update management or atomic deployment management itself.
+This means that an admin would need to ensure that they manually deploy each thing every time, possibly in the correct order and then has to ensure that it did not break.
+If despite all efforts it did break you now end up with no easy way to rollback.
+Ideally one has a git to go from but this might not be a safe operation either and may lead to new issues.
+
+Helm on the other side brings two major things to the table.
+It provides a way to manage the version independent of the product version.
+This is called the \emph{version} of the Helm package, while the version of the product is called \enquote{\emph{appVersion}} in Helm.
+Helm also provides you with a history of deployments.
+This list tracks if a deployment is in progress, successful, failed or rolled back.
+Due to this list helm allows you to seamlessly \emph{rollback} to any prior deployment you made.\footnote{While a \emph{rollback} is possible it is not possible to jump forward afterwards}
+Additionally to the manual rollback Helm has the feature of atomic updates, which automatically will rollback to the last successful deployment version in case of invalid templates, values\footnote{Only syntactic errors} or failures to rollout the deployment in the given timeout.
+
+Beyond the managing of versions and updates Helm also provides a way to share and therefor depend on other charts.
+To do this Helm has their own Chart Repo setup or can use regular \gls{oci} repositories.
+Using these repositories it allows then to define dependencies on existing helm charts.
+This is especially useful to fulfill the goal of having a single deployable bundle for an application.
+For example an API server might want to bundle a PostgreSQL helm chart as a dependency.
+Instead of then defining it themselves it can then depend on existing Charts and provide a consistent experience for consumers in the ecosystem.
+\ No newline at end of file
diff --git a/pages/chapter2.tex b/pages/chapter2.tex
@@ -0,0 +1,270 @@
+A Helm Package follows a strict structure of files and folders.
+The typical structure looks like this\footnote{The test-connection.yaml file can be named anything.
+ This is the default name you get in the official template.}:
+\dirtree{%
+ .1 .
+ .2 Chart.yaml.
+ .2 README.md.
+ .2 templates.
+ .3 \_helpers.yaml.
+ .3 NOTES.txt.
+ .3 tests.
+ .4 test-connection.yaml.
+ .2 values.yaml.
+}
+\clearpage
+
+\section{The \enquote{Chart.yaml}}
+This is the file defining the metadata of the Helm Chart.
+Important fields are the name, description, type, version and appVersion fields.
+Most of these are self-explanatory.
+Below the special fields will be explained.
+
+\begin{figure}[h]
+\begin{minted}[numbers=left, frame=lines,breaklines,breakanywhere,samepage=false]{yaml}
+apiVersion: v2
+name: matrix-neoboard-widget
+description: A whiteboard widget for the Element messenger
+type: application
+version: 0.1.0
+appVersion: "0.0.0"
+home: https://github.com/nordeck/matrix-neoboard
+\end{minted}
+\caption{A simple application Chart.yaml}\label{code:Chart.yaml}
+\end{figure}
+\clearpage
+
+\subsection{The \emph{appVersion} field}
+\lipsum[2-4]
+\subsection{The \emph{maintainers} field}
+\lipsum[2-4]
+\subsection{Other available fields}
+\lipsum[2-4]
+
+\section{The \enquote{values.yaml}}
+
+\subsection{Images}
+
+The core of every application in Kubernetes is the image used for deploying it.
+This is being done in the \enquote{image} section of the \gls{values}.
+
+\begin{figure}[h]
+\begin{minted}[numbers=left, frame=lines,breaklines,breakanywhere,samepage=false]{yaml}
+# This sets the container image more information can be found here: https://kubernetes.io/docs/concepts/containers/images/
+image:
+ repository: nginx
+ # This sets the pull policy for images.
+ pullPolicy: IfNotPresent
+ # Overrides the image tag whose default is the chart appVersion.
+ tag: ""
+# This is for the secretes for pulling an image from a private repository more information can be found here: https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/
+imagePullSecrets: []
+\end{minted}
+\caption{The \enquote{image} section of the \gls{values}}\label{code:image_section}
+\end{figure}
+
+Things to note here are the 3 fields it should contain:
+
+\begin{enumerate}
+ \item{
+ The repository which sets the image name.
+ This would also include things like \enquote{ghcr.io} or other custom repositories used.
+ }
+ \item{
+ The \enquote{pullPolicy} which defines how often it is pulled
+ By default this should be \enquote{IfNotPresent}.
+ For latest tags it automatically defaults however to \enquote{Always} which, as the name says, will always pull the image when a pod is started.
+ }
+ \item{
+ The \enquote{tag} field defines the value after the colon in a docker image.
+ This should stay as an empty string by default since it will be pulled from the chart's \enquote{appVersion} field usually.
+ It is meant to allow a consumer to change this if they need to.
+ }
+\end{enumerate}
+
+Additionally there is the \enquote{imagePullSecrets} field which allows you to pull from private repositories. For more information on this take a look at \url{https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/}
+\clearpage
+
+\subsection{Service Account}
+
+\begin{figure}[h]
+\begin{minted}[numbers=left, frame=lines,breaklines,breakanywhere,samepage=false]{yaml}
+#This section builds out the service account more information can be found here: https://kubernetes.io/docs/concepts/security/service-accounts/
+serviceAccount:
+ # Specifies whether a service account should be created
+ create: true
+ # Automatically mount a ServiceAccount's API credentials?
+ automount: true
+ # Annotations to add to the service account
+ annotations: {}
+ # The name of the service account to use.
+ # If not set and create is true, a name is generated using the fullname template
+ name: ""
+\end{minted}
+\caption{The \enquote{serviceAccount} section of the \gls{values}}\label{code:service_account_section}
+\end{figure}
+
+Service Accounts are required for accessing the resources of the \gls{k8s} Cluster itself.
+They are scoped accounts to the cluster and require most likely more setup in the templates to actually be useful.
+They are commonly used by operators or similar things which listen to or write to resources in the cluster.
+\clearpage
+
+\subsection{Service and Ingress}
+\lipsum[2-4]
+
+\begin{figure}[h]
+\begin{minted}[numbers=left, frame=lines,breaklines,breakanywhere,samepage=false]{yaml}
+service:
+ # This sets the service type more information can be found here: https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types
+ type: ClusterIP
+ # This sets the ports more information can be found here: https://kubernetes.io/docs/concepts/services-networking/service/#field-spec-ports
+ port: 80
+
+# This block is for setting up the ingress for more information can be found here: https://kubernetes.io/docs/concepts/services-networking/ingress/
+ingress:
+ enabled: false
+ className: ""
+ annotations: {}
+ # kubernetes.io/ingress.class: nginx
+ # kubernetes.io/tls-acme: "true"
+ hosts:
+ - host: chart-example.local
+ paths:
+ - path: /
+ pathType: ImplementationSpecific
+ tls: []
+ # - secretName: chart-example-tls
+ # hosts:
+ # - chart-example.local
+\end{minted}
+\caption{The \enquote{service} section and the \enquote{ingress} section of the \gls{values}}\label{code:service_and_ingress_section}
+\end{figure}
+\clearpage
+
+\subsection{Volumes}
+\lipsum[2-4]
+
+\begin{figure}[h]
+\begin{minted}[numbers=left, frame=lines,breaklines,breakanywhere,samepage=false]{yaml}
+# Additional volumes on the output Deployment definition.
+volumes: []
+# - name: foo
+# secret:
+# secretName: mysecret
+# optional: false
+# Additional volumeMounts on the output Deployment definition.
+
+volumeMounts: []
+# - name: foo
+# mountPath: "/etc/foo"
+# readOnly: true
+\end{minted}
+\caption{The \enquote{volumes} section and the \enquote{volumeMounts} section of the \gls{values}}\label{code:volumes_section}
+\end{figure}
+\clearpage
+
+\subsection{Security Contexts}
+\lipsum[2-4]
+
+\begin{figure}[h]
+\begin{minted}[numbers=left, frame=lines,breaklines,breakanywhere,samepage=false]{yaml}
+podSecurityContext: {}
+# fsGroup: 2000
+
+securityContext: {}
+# capabilities:
+# drop:
+# - ALL
+# readOnlyRootFilesystem: true
+# runAsNonRoot: true
+# runAsUser: 1000
+# This is for setting up a service more information can be found here: https://kubernetes.io/docs/concepts/services-networking/service/
+\end{minted}
+\caption{The security context sections of the \gls{values}}\label{code:security_section}
+\end{figure}
+\clearpage
+
+\subsection{Resources}
+\lipsum[2-4]
+
+\begin{figure}[h]
+\begin{minted}[numbers=left, frame=lines,breaklines,breakanywhere,samepage=false]{yaml}
+resources: {}
+# We usually recommend not to specify default resources and to leave this as a conscious
+# choice for the user. This also increases chances charts run on environments with little
+# resources, such as Minikube. If you do want to specify resources, uncomment the following
+# lines, adjust them as necessary, and remove the curly braces after 'resources:'.
+# limits:
+# cpu: 100m
+# memory: 128Mi
+# requests:
+# cpu: 100m
+# memory: 128Mi
+\end{minted}
+\caption{The \enquote{resources} section of the \gls{values}}\label{code:resources_section}
+\end{figure}
+\clearpage
+
+\subsection{Probes}
+
+TODO: Explain why it probably makes no sense to keep in values.yaml
+
+\lipsum[2-4]
+\clearpage
+
+\subsection{Autoscaling}
+\lipsum[2-4]
+
+\begin{figure}[h]
+\begin{minted}[numbers=left, frame=lines,breaklines,breakanywhere,samepage=false]{yaml}
+#This section is for setting up autoscaling more information can be found here: https://kubernetes.io/docs/concepts/workloads/autoscaling/
+autoscaling:
+ enabled: false
+ minReplicas: 1
+ maxReplicas: 100
+ targetCPUUtilizationPercentage: 80
+ # targetMemoryUtilizationPercentage: 80
+\end{minted}
+\caption{The \enquote{autoscaling} section of the \gls{values}}\label{code:autoscaling_section}
+\end{figure}
+\clearpage
+
+\subsection{Misc}
+\lipsum[2-4]
+
+\begin{figure}[h]
+\begin{minted}[numbers=left, frame=lines,breaklines,breakanywhere,samepage=false]{yaml}
+# This will set the replicaset count more information can be found here: https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/
+replicaCount: 1
+
+# This is to override the chart name.
+nameOverride: ""
+fullnameOverride: ""
+
+# This is for setting Kubernetes Annotations to a Pod.
+# For more information checkout: https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/
+podAnnotations: {}
+# This is for setting Kubernetes Labels to a Pod.
+# For more information checkout: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/
+podLabels: {}
+
+nodeSelector: {}
+
+tolerations: []
+
+affinity: {}
+\end{minted}
+\caption{Values which affect the pods or the deployment but are not in a specific group of things}\label{code:misc_values}
+\end{figure}
+\clearpage
+
+\section{The \enquote{NOTES.txt}}
+\lipsum[2-4]
+
+\begin{figure}[h]
+\begin{minted}[numbers=left, frame=lines,breaklines,breakanywhere,samepage=false]{text}
+TODO
+\end{minted}
+\caption{A simple NOTES.txt}\label{code:NOTES.txt}
+\end{figure}
+\clearpage
+\ No newline at end of file
diff --git a/root.tex b/root.tex
@@ -3,8 +3,8 @@
% arara: makeglossaries if found('aux', '@istfilename')
% arara: lualatex: { shell: yes}
% arara: lualatex: { shell: yes }
-\documentclass[english,10pt]{scrbook}
-\input{style.sty}
+\documentclass[english,10pt,a4paper]{scrbook}
+\usepackage{style}
\usepackage{lipsum}
\addbibresource{bibliography.bib}
@@ -31,311 +31,11 @@
\tableofcontents
\chapter{What is Helm?}
-Helm is a system for managing \Glspl{k8sResources} and being able to deliver a simple to deploy bundle to administrators using \Gls{k8s} similar to Docker Compose or Ansible.
-
-It is one of the most used packaging systems in the \Gls{k8s} ecosystem and helps to provide a consistent \gls{ux} in the ecosystem.
-
-\section{Helm as a packaging system}
-Helm itself describes itself as \enquote{The package manager for Kubernetes}\cite{helmauthorsHelm}
-This means it's main goal and design is centered around being able to package an application, deal with dependencies and versioning.
-
-As a result of this Helm is a generic way to define an application deployment.
-In doing that it shares similarities with systems like Ansible, nix and other packaging solutions in the Linux world.
-In the typical Docker illustration style the Helm deployment would be a delivery which contains a given set of Containers which are delivered together to build a single big thing.
-
-\section{Helm as a template engine}
-As part of being a package manager for Kubernetes it has to deal with definitions written in pure YAML.
-Therefor it features a powerful template engine which works similar to how Ansible's template engine works.
-
-Under the hood this is archived by using the Go template language\cite{helmauthorsTemplateFunctionsPipelines,thegoauthorsTemplatePackageText} as well as additional go functions provided to the users.
-
-On top of the template language itself it also provides the option to print messages at the end of the installation or upgrade as well as nesting charts, having libraries for charts and using a global value context.
-These are needed to provide consistent helm charts across a company or set of related charts and to ensure a nice \gls{ux} for those deploying said chart.
-
-\section{Features Helm gives us over pure \Glspl{k8sResources}}
-Pure \Glspl{k8sResources} come with multiple downsides over helm or similar packaging systems for \Gls{k8s}.
-
-\Gls{k8s} brings no update management or atomic deployment management itself.
-This means that an admin would need to ensure that they manually deploy each thing every time, possibly in the correct order and then has to ensure that it did not break.
-If despite all efforts it did break you now end up with no easy way to rollback.
-Ideally one has a git to go from but this might not be a safe operation either and may lead to new issues.
-
-Helm on the other side brings two major things to the table.
-It provides a way to manage the version independent of the product version.
-This is called the \emph{version} of the Helm package, while the version of the product is called \enquote{\emph{appVersion}} in Helm.
-Helm also provides you with a history of deployments.
-This list tracks if a deployment is in progress, successful, failed or rolled back.
-Due to this list helm allows you to seamlessly \emph{rollback} to any prior deployment you made.\footnote{While a \emph{rollback} is possible it is not possible to jump forward afterwards}
-Additionally to the manual rollback Helm has the feature of atomic updates, which automatically will rollback to the last successful deployment version in case of invalid templates, values\footnote{Only syntactic errors} or failures to rollout the deployment in the given timeout.
-
-Beyond the managing of versions and updates Helm also provides a way to share and therefor depend on other charts.
-To do this Helm has their own Chart Repo setup or can use regular \gls{oci} repositories.
-Using these repositories it allows then to define dependencies on existing helm charts.
-This is especially useful to fulfill the goal of having a single deployable bundle for an application.
-For example an API server might want to bundle a PostgreSQL helm chart as a dependency.
-Instead of then defining it themselves it can then depend on existing Charts and provide a consistent experience for consumers in the ecosystem.
+\include{pages/chapter1}
\chapter{Structure of a Helm Package}
+\include{pages/chapter2}
-A Helm Package follows a strict structure of files and folders.
-The typical structure looks like this\footnote{The test-connection.yaml file can be named anything.
-This is the default name you get in the official template.}:
-\dirtree{%
- .1 .
- .2 Chart.yaml.
- .2 README.md.
- .2 templates.
- .3 \_helpers.yaml.
- .3 NOTES.txt.
- .3 tests.
- .4 test-connection.yaml.
- .2 values.yaml.
-}
-\clearpage
-
-\section{The \enquote{Chart.yaml}}
-This is the file defining the metadata of the Helm Chart.
-Important fields are the name, description, type, version and appVersion fields.
-Most of these are self-explanatory.
-Below the special fields will be explained.
-
-\begin{figure}[h]
-\begin{minted}[numbers=left, frame=lines,breaklines,breakanywhere,samepage=false]{yaml}
-apiVersion: v2
-name: matrix-neoboard-widget
-description: A whiteboard widget for the Element messenger
-type: application
-version: 0.1.0
-appVersion: "0.0.0"
-home: https://github.com/nordeck/matrix-neoboard
-\end{minted}
-\caption{A simple application Chart.yaml}\label{code:Chart.yaml}
-\end{figure}
-\clearpage
-
-\subsection{The \emph{appVersion} field}
-\lipsum[2-4]
-\subsection{The \emph{maintainers} field}
-\lipsum[2-4]
-\subsection{Other available fields}
-\lipsum[2-4]
-
-\section{The \enquote{values.yaml}}
-
-\subsection{Images}
-
-The core of every application in Kubernetes is the image used for deploying it.
-This is being done in the \enquote{image} section of the \gls{values}.
-
-\begin{figure}[h]
-\begin{minted}[numbers=left, frame=lines,breaklines,breakanywhere,samepage=false]{yaml}
-# This sets the container image more information can be found here: https://kubernetes.io/docs/concepts/containers/images/
-image:
- repository: nginx
- # This sets the pull policy for images.
- pullPolicy: IfNotPresent
- # Overrides the image tag whose default is the chart appVersion.
- tag: ""
-# This is for the secretes for pulling an image from a private repository more information can be found here: https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/
-imagePullSecrets: []
-\end{minted}
-\caption{The \enquote{image} section of the \gls{values}}\label{code:image_section}
-\end{figure}
-
-Things to note here are the 3 fields it should contain:
-
-\begin{enumerate}
- \item The repository which sets the image name. This would also include things like \enquote{ghcr.io} or other custom repositories used.
- \item The \enquote{pullPolicy} which defines how often it is pulled. By default this should be \enquote{IfNotPresent}. For latest tags it automatically defaults however to \enquote{Always} which, as the name says, will always pull the image when a pod is started.
- \item The \enquote{tag} field defines the value after the colon in a docker image. This should stay as an empty string by default since it will be pulled from the chart's \enquote{appVersion} field usually. It is meant to allow a consumer to change this if they need to.
-\end{enumerate}
-
-Additionally there is the \enquote{imagePullSecrets} field which allows you to pull from private repositories. For more information on this take a look at \url{https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/}
-\clearpage
-
-\subsection{Service Account}
-
-\begin{figure}[h]
-\begin{minted}[numbers=left, frame=lines,breaklines,breakanywhere,samepage=false]{yaml}
-#This section builds out the service account more information can be found here: https://kubernetes.io/docs/concepts/security/service-accounts/
-serviceAccount:
- # Specifies whether a service account should be created
- create: true
- # Automatically mount a ServiceAccount's API credentials?
- automount: true
- # Annotations to add to the service account
- annotations: {}
- # The name of the service account to use.
- # If not set and create is true, a name is generated using the fullname template
- name: ""
-\end{minted}
-\caption{The \enquote{serviceAccount} section of the \gls{values}}\label{code:service_account_section}
-\end{figure}
-
-Service Accounts are required for accessing the resources of the \gls{k8s} Cluster itself.
-They are scoped accounts to the cluster and require most likely more setup in the templates to actually be useful.
-They are commonly used by operators or similar things which listen to or write to resources in the cluster.
-\clearpage
-
-\subsection{Service and Ingress}
-\lipsum[2-4]
-
-\begin{figure}[h]
-\begin{minted}[numbers=left, frame=lines,breaklines,breakanywhere,samepage=false]{yaml}
-service:
- # This sets the service type more information can be found here: https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types
- type: ClusterIP
- # This sets the ports more information can be found here: https://kubernetes.io/docs/concepts/services-networking/service/#field-spec-ports
- port: 80
-
-# This block is for setting up the ingress for more information can be found here: https://kubernetes.io/docs/concepts/services-networking/ingress/
-ingress:
- enabled: false
- className: ""
- annotations: {}
- # kubernetes.io/ingress.class: nginx
- # kubernetes.io/tls-acme: "true"
- hosts:
- - host: chart-example.local
- paths:
- - path: /
- pathType: ImplementationSpecific
- tls: []
- # - secretName: chart-example-tls
- # hosts:
- # - chart-example.local
-\end{minted}
-\caption{The \enquote{service} section and the \enquote{ingress} section of the \gls{values}}\label{code:service_and_ingress_section}
-\end{figure}
-\clearpage
-
-\subsection{Volumes}
-\lipsum[2-4]
-
-\begin{figure}[h]
-\begin{minted}[numbers=left, frame=lines,breaklines,breakanywhere,samepage=false]{yaml}
-# Additional volumes on the output Deployment definition.
-volumes: []
-# - name: foo
-# secret:
-# secretName: mysecret
-# optional: false
-# Additional volumeMounts on the output Deployment definition.
-
-volumeMounts: []
-# - name: foo
-# mountPath: "/etc/foo"
-# readOnly: true
-\end{minted}
-\caption{The \enquote{volumes} section and the \enquote{volumeMounts} section of the \gls{values}}\label{code:volumes_section}
-\end{figure}
-\clearpage
-
-\subsection{Security Contexts}
-\lipsum[2-4]
-
-\begin{figure}[h]
-\begin{minted}[numbers=left, frame=lines,breaklines,breakanywhere,samepage=false]{yaml}
-podSecurityContext: {}
-# fsGroup: 2000
-
-securityContext: {}
-# capabilities:
-# drop:
-# - ALL
-# readOnlyRootFilesystem: true
-# runAsNonRoot: true
-# runAsUser: 1000
-# This is for setting up a service more information can be found here: https://kubernetes.io/docs/concepts/services-networking/service/
-\end{minted}
-\caption{The security context sections of the \gls{values}}\label{code:security_section}
-\end{figure}
-\clearpage
-
-\subsection{Resources}
-\lipsum[2-4]
-
-\begin{figure}[h]
-\begin{minted}[numbers=left, frame=lines,breaklines,breakanywhere,samepage=false]{yaml}
-resources: {}
-# We usually recommend not to specify default resources and to leave this as a conscious
-# choice for the user. This also increases chances charts run on environments with little
-# resources, such as Minikube. If you do want to specify resources, uncomment the following
-# lines, adjust them as necessary, and remove the curly braces after 'resources:'.
-# limits:
-# cpu: 100m
-# memory: 128Mi
-# requests:
-# cpu: 100m
-# memory: 128Mi
-\end{minted}
-\caption{The \enquote{resources} section of the \gls{values}}\label{code:resources_section}
-\end{figure}
-\clearpage
-
-\subsection{Probes}
-
-TODO: Explain why it probably makes no sense to keep in values.yaml
-
-\lipsum[2-4]
-\clearpage
-
-\subsection{Autoscaling}
-\lipsum[2-4]
-
-\begin{figure}[h]
-\begin{minted}[numbers=left, frame=lines,breaklines,breakanywhere,samepage=false]{yaml}
-#This section is for setting up autoscaling more information can be found here: https://kubernetes.io/docs/concepts/workloads/autoscaling/
-autoscaling:
- enabled: false
- minReplicas: 1
- maxReplicas: 100
- targetCPUUtilizationPercentage: 80
- # targetMemoryUtilizationPercentage: 80
-\end{minted}
-\caption{The \enquote{autoscaling} section of the \gls{values}}\label{code:autoscaling_section}
-\end{figure}
-\clearpage
-
-\subsection{Misc}
-\lipsum[2-4]
-
-\begin{figure}[h]
-\begin{minted}[numbers=left, frame=lines,breaklines,breakanywhere,samepage=false]{yaml}
-# This will set the replicaset count more information can be found here: https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/
-replicaCount: 1
-
-# This is to override the chart name.
-nameOverride: ""
-fullnameOverride: ""
-
-# This is for setting Kubernetes Annotations to a Pod.
-# For more information checkout: https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/
-podAnnotations: {}
-# This is for setting Kubernetes Labels to a Pod.
-# For more information checkout: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/
-podLabels: {}
-
-nodeSelector: {}
-
-tolerations: []
-
-affinity: {}
-\end{minted}
-\caption{Values which affect the pods or the deployment but are not in a specific group of things}\label{code:misc_values}
-\end{figure}
-\clearpage
-
-\section{The \enquote{NOTES.txt}}
-\lipsum[2-4]
-
-\begin{figure}[h]
-\begin{minted}[numbers=left, frame=lines,breaklines,breakanywhere,samepage=false]{text}
-TODO
-\end{minted}
-\caption{A simple NOTES.txt}\label{code:NOTES.txt}
-\end{figure}
-\clearpage
%%%%%%%%%%%%%%%%%%%%%%%%
\cleardoublepage
diff --git a/style.sty b/style.sty
@@ -1,4 +1,8 @@
-\usepackage[english]{babel}
+\usepackage{polyglossia}
+\setdefaultlanguage{english}
+\usepackage{fontspec}
+\usepackage{fontspec}
+\usepackage{microtype}
\usepackage{scrhack}
\usepackage[headsepline,automark,autooneside=false]{scrlayer-scrpage}
\usepackage{xcolor}
@@ -15,6 +19,7 @@
\usepackage{graphicx}
\usepackage{lmodern}
\usepackage{dirtree}
+\usepackage{enumerate}
\usepackage[acronym]{glossaries-extra}
\usepackage[
backend=biber,
