A deployment describes a desired state, and the deployment controller changes the actual state to the desired state at a controlled rate. You can define Deployments to create new ReplicaSets, or to remove existing Deployments and adopt all their resources with new Deployments.
Below is the YAML file we use to create the deployment. The required amount of replicas is set here, but it can be changed later without having to re-deploy the deployment. The image we declare is the Gitlab image we create of the application. Imagepullsecrets refers to our Kubernetes secret, which we discuss in this section [Secrets](/Kubernetes/Constructs#secrets)
Below is the YAML file we use to create the deployment. The required amount of replicas is set here, but it can be changed later without having to re-deploy the deployment. The image we declare is the GitLab image we create of the application. Imagepullsecrets refers to our Kubernetes secret, which we discuss in this section [Secrets](/Kubernetes/Constructs#secrets)
```
apiVersion: apps/v1
...
...
@@ -72,6 +72,7 @@ kubectl logs {podname}
In our project, services and deployments and included in the same YAML file. They are separated in the YAML file using three dashes --- to indicate where one begins and the other ends. We do this to unclutter the repository and because deployments and services are very closely linked.
# Ingress
Ingress is actually NOT a type of service. Instead, it sits in front of multiple services and act as a “smart router” or entrypoint into your cluster.
Ingress exposes HTTP and HTTPS routes from outside the cluster to services within the cluster. An ingress will connect to a service and then expose that service externally on a public IP address.
Annotations in Ingress let Kubernetes know specific environment setups needed for the Ingress. Our web front-end is Angular project, which is built in an Nginx container. *nginx.ingress.kube...* tells the Nginx environment where URI traffic must be re-directed to. We also provide our Ingress with a host, which is a DNS address. Our DNS host name is an Azure virtual machine DNS. The backend refers to a kubernetes service we have created that is exposed on port 80.
...
...
@@ -112,7 +113,7 @@ A Job creates one or more Pods and ensures that a specified number of them succe
In our project, we found this useful for testing our controllers database connection. Rather than having a fully functional controller application, we built a test program that connected to our cluster, performed a simple selection and printed results. The test program was best suited as a job because we did not want the pod trying to select and print continuously, we just needed it to run once.
Below is the YAML file, which we use to create a Job. As in the deployment we use the image from the Gitlab pipeline and we have declared the Kubernetes secret. The main difference from a deployment is the `restartpolicy` being set to Never and a `backofflimit` is set to 0 to ensure the job runs once. We declare a command to execute a run of the program in *command: ["dotnet", "postgrestest.dll"]* so the program is triggered open creation like hitting the run button in IDE.
Below is the YAML file, which we use to create a Job. As in the deployment we use the image from the GitLab pipeline and we have declared the Kubernetes secret. The main difference from a deployment is the `restartpolicy` being set to Never and a `backofflimit` is set to 0 to ensure the job runs once. We declare a command to execute a run of the program in *command: ["dotnet", "postgrestest.dll"]* so the program is triggered open creation like hitting the run button in IDE.
```
...
...
@@ -161,13 +162,13 @@ An operator is used to
- can simulate failures to test cluster resistance
- publishing a service to applications, that don’t support Kubernetes API's to discover them
Many operators cover a broad range of not just SQL languages but also all types of applications. We discovered multiple controllers for PostgreSQL and Cassandra. The criteria for selection was - they operator must be an open source projects with good community support. Postgressql-operator and casskop meet our criteria and they were used going forward. These operators could be deployed manually by downloading there YML files from respective Git repositories and you could edit them and create customization to them. The standard deployment of those operators meets are requirements so no adjustment was made to them.
Many operators cover a broad range of not just SQL languages but also all types of applications. We discovered multiple controllers for PostgreSQL and Cassandra. The criteria for selection was - the operator must be an open source projects with good community support. `Zalando postgres-operator` and `casskop` meet our criteria and they were used going forward. These operators could be deployed manually by downloading there YAML files from respective Git repositories and you could edit them and create customization to them. The standard deployment of those operators meets our requirements so no adjustment was made to them.
We deployed our operators using `kubectl apply`
We deployed our operators using `kubectl apply` (it can be used with kubectl 1.14 or newer)
This references an external link were the correct YML files are acquired and used to create our PostgreSQL operator.
This references an external link were the correct YAML files are acquired and used to create our PostgreSQL operator.
CassKop uses Helm to assist it install the correct files to create an operator
...
...
@@ -196,7 +197,7 @@ In the database connections we use the name of the operator service *postgres-op
# Namespaces
Kubernetes provides namespaces, which act as different environments. You can create and namespace using a YAML file. The YAML file below will create a name space of name **staging**
Kubernetes provides namespaces, which act as different environments. You can create a namespace using a YAML file. The YAML file below will create a name space of name **staging**
Kubernetes Secrets let you store and manage sensitive information, such as passwords, OAuth tokens, and ssh keys. Storing confidential information in a Secret is safer and more flexible than putting it verbatim in a Pod definition or in a container image.
Kubernetes Secrets let you store and manage sensitive information, such as passwords, OAuth tokens, and SSH keys. Storing confidential information in a Secret is safer and more flexible than putting it verbatim in a Pod definition or in a container image.
We used secrets to create secure connection between our environment in Gitlab and Azure. Both were created in the same manner but with different details.
We used secrets to create secure connection between our environment in GitLab and Azure. Both were created in the same manner but with different details.
## Azure
Connecting to an Azure image registry requires two steps:
- create the credentials in Azure portal
- create our Kubernetes secret in Azure
### Azure portal (creating the credentials linking to azure image repository)
### Azure portal (creating the credentials linking to Azure image repository)
This is created by navigating in the Azure portal to your container repository, which is named `imgregdocker`.
Using the Azure CLI with bash style command line (create an azure storage unit if needed)
Using the Azure CLI with bash style command line (create an Azure storage unit if needed)
Using the CLI perform these commands.
Set up variables, which will be used for commands later
-Set up variables, which will be used for commands later
```
ACR_NAME=imgregdocker
SERVICE_PRINCIPAL_NAME=acr-service-principal-sr
```
create the username and password
- Create the username and password
```
ACR_REGISTRY_ID=$(az acr show --name $ACR_NAME --query id --output tsv)
-*regcred* will become the name of our secret and it was what we reference in yamls as the imagepullsecret
-*--docker-server=* is the public dns name of our image Azure Image Registry
-*regcred* will become the name of our secret and it was what we reference in YAML files as the imagepullsecret
-*--docker-server=* is the public DNS name of our image in Azure Image Registry
-*--docker-username=* is the Service principal ID from Azure
-*--docker-password=* is the Service principal password from Azure
-*email=* is the email address of the azure account
-*email=* is the email address of the Azure account
## Gitlab
Connect to Gitlab Image repository requires two steps
- creating of Gitlab token in Gitlab
## GitLab
Connect to GitLab Image repository requires two steps
- creating of GitLab token in GitLab
- issuing that token to create our secret in Kubernetes.
### Gitlab personal access token creation
- In Gitlab head to your account settings by clicking your portrait in top right hand corner > settings
### GitLab personal access token creation
- In GitLab head to your account settings by clicking your portrait in top right hand corner > settings
- On the left hand side there is a menu, select the personal access tokens option
- Select all the scopes by ticking the boxes and click create a personnel access token
- Gitlab will then display your personal access token (be sure to save this somewhere as this is the only time you will see it). After this, you will not be able to view the key again and need to create another key if you lose it
- GitLab will then display your personal access token (be sure to save this somewhere as this is the only time you will see it). After this, you will not be able to view the key again and need to create another key if you lose it
### Kubernetes Secret creation
To create our secret we need to execute a command that contains our Gitlab credentials with our personal access
To create our secret we need to execute a command that contains our GitLab credentials with our personal access
-*gitcreds* will become the name of our secret and it was what we reference in yamls as the imagepullsecret
-*--docker-server=* is the address in Gitlab our project is contained in
-*--docker-username=* is the Gitlab username
-*--docker-password=* is the Gitlab personal access token
-*--docker-server=* is the address in GitLab our project is contained in
-*--docker-username=* is the GitLab username
-*--docker-password=* is the GitLab personal access token
# Services
A service is an abstract way to expose an application running on a set of Pods as a network service. It connects to our deployment and expose them on the ports specified. There are different types of selectors you can choose from and deepening on your choice Kubernetes will provision the specified type. We use `LoadBalancer` as when it is hosted in a cloud environment it uses the settings from that environment whether as nodeport you must declare these settings.
A service is an abstract way to expose an application running on a set of Pods as a network service. It connects to our deployment and expose them on the ports specified. There are different types of selectors you can choose from and depending on your choice Kubernetes will provision the specified type. We use `LoadBalancer` as when it is hosted in a cloud environment it uses the settings from that environment whether as `NodePort` you must declare these settings.
Below is the YAML file, which we use to create services with our project. The name and app selector are important as they help link to our deployment. We have specified our target port as 80 and we use the TCP protocol.
