2. Deploy Applications Flashcards
- Deploy applications from resource manifests
App
# with oc new-app
oc new-app –file=./example/my-app.yaml
# with usual create/apply
oc create -f my_manifest.yml
oc apply -f my_manifest.yml
- Use Kustomize overlays to modify application configurations
Kustomize is a configuration management tool to make declarative changes to application configurations and components and preserve the original base YAML files.
You group in a directory the Kubernetes resources that constitute your application and then use kustomize to copy and adapt these resource files to your environments and clusters.
Overlays
Kustomize overlays declarative YAML artifacts, or patches, that override the general settings without modifying the original files. The overlay directory contains a kustomization.yaml file.
To get find out more, check
Declarative Management of Kubernetes Objects Using Kustomize documentation
Kustomize Github repo
kustomize
## render the files/temples
oc kustomize overlays/staging
apiVersion: v1
data:
enable: “true”
msg: Welcome!
kind: ConfigMap
metadata:
name: hello-app-configmap-9tcmf95d77
namespace: hello-stage
—
apiVersion: apps/v1
kind: Deployment
…output omitted…
## Apply files directly with -k option
oc apply -k overlays/staging
- Deploy applications from images, OpenShift templates, and Helm charts
From images
Deploy App
# with oc new-app
oc new-app –name db-image -l team=blue –image registry.ocp4.example.com:8443/rhel9/mysql-80:1 \
-e MYSQL_USER=developer \
-e MYSQL_PASSWORD=developer \
-e MYSQL_ROOT_PASSWORD=redhat
# with oc run
oc run example-pod \
–image=registry.access.redhat.com/ubi8/httpd-24 \
–env GREETING=’Hello from the awesome container’ \
–port 8080
# with oc create
oc create deployment my-db –image registry.ocp4.example.com:8443/rhel9/mysql-80:1
From templates
Deploy and update applications from resource manifests that are packaged as OpenShift templates.
A template is a Kubernetes custom resource that describes a set of Kubernetes resource configurations.
Templates can have parameters. You can create a set of related Kubernetes resources from a template by processing the template, and providing values for the parameters.
Find out more in templates documentation.
oc template/new-app
oc get templates -n openshift
oc describe template cache-service -n openshift
# process template
oc process my-cache-service -o yaml
oc process my-cache-service -p TOTAL_CONTAINER_MEM=1024 -p APPLICATION_USER=’cache-user’ -o yaml
## with exisiting template file
oc process -f my-cache-service-template.yaml
## Use –parameters option to view only the parameters that a template uses
oc process –parameters cache-service -n openshift
# create App from template with new-app
oc new-app –template=cache-service
oc new-app -l team=red –template mysql-persistent -p MYSQL_USER=developer -p MYSQL_PASSWORD=developer
# create/upload new template from files
oc create -f /path/to/template/manifests.yml
helm Charts
Use usual helm commands. Find out more in Helm documentation
helm
# list repo
helm repo list
Error: no repositories to show
# add repo
helm repo add do280-repo http://helm.ocp4.example.com/charts
# list all charts version in the repo do280-repo
helm search repo –version
NAME CHART VERSION APP VERSION …
do280-repo/etherpad 0.0.7 latest …
do280-repo/etherpad 0.0.6 latest …
…output omitted..
# install do280-repo/etherpad 0.0.6
## examine the chart variables
helm show values do280-repo/etherpad –version 0.0.6
## create values.yml with variables
## install the release
helm install example-app do280-repo/etherpad -f values.yaml –version 0.0.6
## upgrade to the 0.0.7
helm upgrade example-app do280-repo/etherpad -f values.yaml –version 0.0.7
# view the history of release
helm history example-app
- Deploy jobs to perform one-time tasks
Jobs
oc create job date-job –image registry.access.redhat.com/ubi8/ubi – /bin/bash -c “date”
oc create job date-loop –image registry.ocp4.example.com:8443/ubi9/ubi \
– /bin/bash -c “for i in {1..30}; do date; done”
oc get jobs
- Manage application deployments
Deployment
# with oc create
oc create deployment my-db –image registry.ocp4.example.com:8443/rhel9/mysql-80:1
oc get deploy,po
- Work with replica sets
Use oc scale deployment/example –replicas=3
- Work with labels and selectors
Label - Selector Filtering
Use usual -l, -L to filter the resources
- Configure services
Services
# create a service
oc create service -h
oc create service clusterip mysvc –tcp=8080:8080 –dry-run=server -o yaml
# expose an existing workload
## create workload
oc create deployment sakila-app –image registry.ocp4.example.com:8443/redhattraining/do180-httpd-app:v1
oc expose deployment sakila-app –name sakila-svc –port 8080 –target-port 8080
service/sakila-svc exposed
oc create deployment satir-app –image registry.ocp4.example.com:8443/redhattraining/do180-httpd-app:v1
oc expose deployment satir-app –name satir-svc –port 8080 –target-port 8080
oc get svc,ep
- Expose both HTTP and non-HTTP applications to external access
Route and Ingress are the main resources for handling ingress traffic.
When you create an ingress object, an asscociated route(with no assigned port) is also created
Expose
# create route by exposing an existing service
oc expose service satir-svc –name satir
route.route.openshift.io/satir exposed
# if you omit the hostname, the default is: <route-name>-<project-name>.<default-domain>.
oc get routes
NAME HOST/PORT ... SERVICES PORT ...
satir satir-web-applications.apps.ocp4.example.com ... satir-svc 8080 ...</default-domain></project-name></route-name>
# create an ingress object
oc create ingress ingr-sakila –rule “ingr-sakila.apps.ocp4.example.com/*=sakila-svc:8080”
ingress.networking.k8s.io/ingr-sakila created
oc get ingress
NAME … HOSTS ADDRESS PORTS …
ingr-sakila … ingr-sakila.apps.ocp4.example.com router…com 80 …
oc get routes
NAME HOST/PORT … SERVICES PORT
ingr-sakila… ingr-sakila.apps.ocp4.example.com … sakila-svc <all>
satir satir-web-applications.apps.ocp4.example.com ... satir-svc 8080</all>
# create a route
oc create route -h
oc create route edge myroute –service=mysvc_name –port 8080
Annotate route & ingress to add features like sticky sessions
Routes Annotations
oc annotate ingress ingr-sakila ingress.kubernetes.io/affinity=cookie
ingress.networking.k8s.io/ingr-sakila annotated
oc annotate route satir router.openshift.io/cookie_name=”hello”
route.route.openshift.io/satir annotated
Expose non-HTTP/SNI Applications
You can use service types LoadBalancer or NodePort to expose your non-HTTP application
Expose - Loadbalancer
# expose a deployment as Loadbalancer service type
oc expose deployment/virtual-rtsp-1 –target-port=8554 –type=LoadBalancer
oc get services
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
virtual-rtsp-1 LoadBalancer 172.30.4.18 192.168.50.20 8554:32170/TCP 59
- Work with operators such as MetalLB and Multus
MetalLB
MetalLB is a load balancer component that provides a load balancing service for clusters that do not run on a cloud provider, such as a bare metal cluster,
or clusters that run on hypervisors. MetalLB operates in two modes: layer 2 and Border Gateway Protocol (BGP).
MetalLB is an operator that you can install with the Operator Lifecycle Manager. After installing the operator, you must configure MetalLB through
its custom resource definitions. In most situations, you must provide MetalLB with an IP address range.
More information on MetalLB in the documentation
Multus Secondary Networks
Expose applications to external access by using a secondary network.
The Multus CNI (container network interface) plug-in helps to attach pods to custom networks.
These custom networks can be either existing networks outside the cluster, or custom networks that are internal to the cluster.
onfiguring Secondary Networks
To use existing custom networks, first you must make available the network on cluster nodes.
You can use operators, such as the Kubernetes NMState operator or the SR-IOV (Single Root I/O Virtualization) network operator, to customize node network configuration.
With these operators, you define custom resources to describe the intended network configuration, and the operator applies the configuration.
The SR-IOV network operator configures SR-IOV network devices for improved bandwidth and latency on certain platforms and devices.
Attaching Secondary Network
To configure secondary networks, create a NetworkAttachmentDefinition resource. Alternatively, update the configuration of the cluster network operator to add a secondary network
NetworkAttachmentDefinition
apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
name: custom
spec:
config: |-
{
“cniVersion”: “0.3.1”,
“name”: “custom”,
“type”: “host-device”,
“device”: “ens4”,
“ipam”: {
“type”: “static”,
“addresses”: [
{“address”: “192.168.51.10/24”}
]
}
}
Pod Annotations:
Network attachment resources are namespaced, and are available only to pods in their namespace.
When the cluster has additional networks, you can add the k8s.v1.cni.cncf.io/networks: your-secondary-network-name annotation to the pod’s template to use one of the additional networks.
Network Annotations
apiVersion: apps/v1
kind: Deployment
metadata:
name: example
namespace: example
spec:
selector:
matchLabels:
app: example
name: example
template:
metadata:
annotations:
k8s.v1.cni.cncf.io/networks: example ### add annotation in template section
labels:
app: example
name: example
spec:
…output omitted…
Show status
oc get pod example \
-o jsonpath=’{.metadata.annotations.k8s.v1.cni.cncf.io/networks-status}’
[{
“name”: “ovn-kubernetes”,
“interface”: “eth0”,
“ips”: [
“10.8.0.59”
],
“mac”: “0a:58:0a:08:00:3b”,
“default”: true,
“dns”: {}
},{
“name”: “non-http-multus/example”, # custom network
“interface”: “net1”,
“ips”: [
“1.2.3.4”
],
“mac”: “52:54:00:01:33:0a”,
“dns”: {}
}]
Take a look in Multiple Networks documentation.
