Simon Krenger

One of the newer features in Kubernetes (1.30 and later) is the Kubelet Checkpoint API. This new API allows users to create a stateful copy of a running container, a functionality which is often used for forensics or for debugging.

In Kubernetes installations where this feature is enabled, a checkpoint can be created by accessing the respective Kubelet API via curl or similar. In the following example I am also using the Kubernetes API /proxy endpoint (the same can also be done on the Node locally via localhost:10250/checkpoint/...):

$ curl -k -X POST --header "Authorization: Bearer $TOKEN" "$KUBERNETES_API_URL/api/v1/nodes/$NODE_NAME/proxy/checkpoint/$NAMESPACE_NAME/$POD_NAME/$CONTAINER_NAME"
{"items":["/var/lib/kubelet/checkpoints/checkpoint-fedora-74d79dd7f4-csrmg_skrenger-container-2024-12-12T12:56:19Z.tar"]}

In OpenShift Container Platform (OCP) 4, most of the functionality is controlled by Operators. To see the currently installed Operators and also their status, use the following command:

$ oc get clusteroperators
NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE
authentication                             4.6.4     True        False         False      12m
cloud-credential                           4.6.4     True        False         False      38m
cluster-autoscaler                         4.6.4     True        False         False      32m
config-operator                            4.6.4     True        False         False      33m
console                                    4.6.4     True        False         False      21m
csi-snapshot-controller                    4.6.4     True        False         False      27m
dns                                        4.6.4     True        False         False      31m
etcd                                       4.6.4     True        False         False      32m
image-registry                             4.6.4     True        False         False      25m
ingress                                    4.6.4     True        False         False      24m
insights                                   4.6.4     True        False         False      33m
kube-apiserver                             4.6.4     True        False         False      30m
kube-controller-manager                    4.6.4     True        False         False      31m
kube-scheduler                             4.6.4     True        False         False      31m
kube-storage-version-migrator              4.6.4     True        False         False      24m
machine-api                                4.6.4     True        False         False      27m
machine-approver                           4.6.4     True        False         False      32m
machine-config                             4.6.4     True        False         False      32m
marketplace                                4.6.4     True        False         False      32m
monitoring                                 4.6.4     True        False         False      23m
network                                    4.6.4     True        False         False      33m
node-tuning                                4.6.4     True        False         False      33m
openshift-apiserver                        4.6.4     True        False         False      27m
openshift-controller-manager               4.6.4     True        False         False      24m
openshift-samples                          4.6.4     True        False         False      26m
operator-lifecycle-manager                 4.6.4     True        False         False      32m
operator-lifecycle-manager-catalog         4.6.4     True        False         False      32m
operator-lifecycle-manager-packageserver   4.6.4     True        False         False      27m
service-ca                                 4.6.4     True        False         False      33m
storage                                    4.6.4     True        False         False      32m

You can find the description of the default Operators in the documentation.

This will only list the Red Hat Operators that are installed as part of the cluster. These are all controlled by the ClusterVersionOperator, which is the “Master-Operator” of the cluster controlling all others.

If you want to list all Operators that were installed via the Operator Lifecycle Manager (OLM), you can use the following command:

$ oc get subscriptions --all-namespaces

For OpenShift 4, the upgrade paths are kept in the cincinnati-graph-data repository as YAML files and then exposed via an API.

There is a Red Hat Solution describing how this data can be queried via api.openshift.com and how you can use this data in your automation:

$ curl -sH 'Accept:application/json' 'https://api.openshift.com/api/upgrades_info/v1/graph?channel=fast-4.2&arch=amd64' | jq .

While this data is quite helpful for automation (the Solution also describes helpful queries), it is not very nice to look at the raw data. If you are looking for a graphical presentation of that data, you should check out this wonderful website that is maintained by a Red Hat colleague with hourly generated data: www.ocp-upgrade.net

Even though I am not really happy about the new recertification requirements from Oracle, I took it to myself to refresh my OCP certificate. I completed the exam 1Z0-060 and can call myself now a “Oracle Database 12c Administrator Certified Professional”.

Although I am not allowed to disclose information about the exam, I must say that the I found this exam easier than previous exams. Since the exam is a multiple-choice exam, one can often answer the questions by just guessing or by exclusion principle…

So today I was disappointed to read that Oracle introduced a recertification requirement for the Oracle Database Administrator certificates:

The Oracle Certification Program is implementing a recertification requirement for our Oracle Database Administration credentials.
[..]
This new policy requires you as an Oracle Database credential holder to demonstrate your currency with the most recent trends, techniques and best practices in Oracle Database technology.

More details can be found on the new website for these new requirements.

Recertification, really? And probably you’ll then proceed to tell me that I need to attend an Oracle University course to upgrade my certification to a newer release, yeah? This is bullshit…

I am happy to report that I finished my Oracle Certified Professional certification this Monday by taking the “1Z0-053 Oracle Database 11g: Administration II” exam. So officially, I am now a “Oracle Database 11g Administrator Certified Professional”.

While this certificate is certainly nice to have, I still think that there are many topics of Oracle Database that I still have to explore. So stay tuned for more insights in this blog :).

In preparation for my OCP examination, I am currently playing around with ASM. For this purpose I am using an AWS instance to install and configure my database. So I added my disks, partitioned them using fdisk and installed ASMLib to manage them. But when I wanted to issue the createdisk command, this happened:

[root@ip-10-234-66-103 ~]# oracleasm createdisk DATA0 /dev/xvdc1
Device "/dev/xvdc1" is already labeled for ASM disk ""

So what is the problem here? Before deciding to use ASMLib, I tried to add the disks using only ASM commands from within the ASM instance, which failed for some reason. This is why I then switched to ASMLib.