Overview:
- OpenShift cluster, applications, and users administration
- Maintenance and Troubleshooting of Kubernetes clusters
- Security management of the cluster
Software Overview:
- Red Hat OpenShift Container Platform (ROCP), based on Kubernetes
- Single-node base metal (SNO), a single-node implementation, meaning a RHOCP cluster running on a single-node (host server)
- User Provisioned Infrastructure (UPI)
- Declarative resource management for specifying desired states that the system will configure, vs imperative commands that manually configure the system step-by step
- Cluster applications consist of multiple resources that are configured together, and each resource has a definition document and a configuration applied.
Imperative Commands vs. Declarative Commands:
Imperative commands in Kubernetes directly manipulate the state of the system by executing specific commands, while declarative commands involve defining the desired state in a configuration file that cumulates to what the state will be.
The imperative approach allows the administrator to issue step-by-step commands, where the result of each gives the administrator the flexibility of adaptability based on the last command's response, whereas the declarative are written instructions, called manifests which Kubernetes read and apply cluster changes to meet the state the resource manifest defines. The industry generally prefers the latter due to:
- Increased reproducibility/consistency
- Better version control
- Better GitOps methodology
Resource Manifest:
- file in YAML or JSON format, and thus a single document which can be version-controlled readily
- simplify administration by encapsulating all the attributes of an application in a file or a set of related files which are then can be run repeatably with consistent results allowing for the CI/CD pipelines of GitOps.
Imperative command example:
[admin@rocp ~]$ kubectl create deployment mysql-pod --port 3306 --image registry.ocp4.mindwatering.net:8443/mysql:latest --env="MYSQL_USER='dbuser'" --env="MYSQL_PASSWORD='hardpassword' --env="MYSQL_DATABASE='dbname'"
deployment.apps/mysql-pod created
Adding the --save-config and --dry-run=client options, respectively allow what would have been run to be saved in that resources configuration nomenclature into a manifest file.
[admin@rocp ~]$ kubectl create deployment mysql-pod --namespace=mysql-manifest --port 3306 --image registry.ocp4.mindwatering.net:8443/mysql:latest --replicas=1 --env="MYSQL_USER='dbuser'" --env="MYSQL_PASSWORD='hardpassword' --env="MYSQL_DATABASE='dbname'" --save-config --dry-run=client > ~/mysql-deployment.yaml
[admin@rocp ~]$ cat mysql-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
namespace: mysql-manifest
annotations:
...
creationTimestamp: null
labels:
app: mysql-pod
name: mysql-pod
spec:
replicas: 1
selector:
matchLabels:
app: mysql-pod
strategy: {}
template:
metadata:
creationTimestamp: null
labels:
app: mysql-pod
spec:
containers:
- image: registry.ocp4.mindwatering.net:8443/mysql:latest
name: mysql
env:
- MYSQL_USER=dbuser
- MYSQL_PASSWORD=hardpassword
- MYSQL_DATABASE=dbname
ports:
- containerPort: 3306
resources: {}
status: {}
Notes:
- The order of parameters matter. For example, if the --env are moved earlier in the command they are not added.
- Never include the password like this, abstract with the credential.
- Add the service resource mansifest to this one as one file separated by the --- delineator, or keep in separate files which are loaded together.
The declarative command syntax:
[admin@rocp ~]$ kubectl create -f ~/mysql-deployment.yaml
IMPORTANT:
- The kubectl create above does not take into account for the current running state of the resource, in this case, the mysql-pod resource. The kubectl create would cause error because the mysql-pod is already running.
- The kubectl apply command tries to apply updates w/o causing issues. Executing kubectl create -f against a manifest for a live resource gives an error. In contrast, the kubectl apply -f command is declarative, and considers the difference between the current resource state in the cluster and the intended resource state that is expressed in the manifest.
To help verify syntax and whether an applied manifest update would succeed, use the --dry-run=server and the --validate=true flags. The dry-run=client does not have the validation of the cluster resource controllers server-side dry-run.
[admin@rocp ~]$ kubectl apply -f ~/mysql-deployment.yaml --dry-run=server --validate=true
deployment.apps/hello-openshift created (server dry-run)
Diff Tools vs kubectl diff:
Kubernetes resource controllers automatically add annotations and attributes to the live resource that make the output of other text-based diff tools reporti many differences that have no impact on the resource configuration, causing confusion and wasted time. Using the kubectl diff command confirms that a live resource matches, or does not match, a resource configuration that a manifest provides. Because other tools cannot know all details about how any controllers might change a resource, the the kubectl diff tool handles whether the cluster would determine if a change is meaningful.
Moreover, GitOps tools depend on the kubectl diff command to determine whether anyone changed resources outside the GitOps workflow.
previous page
|