patch

Kubernetes: patching container arguments array with kubectl and jq

The need to configure a specific pod’s container arguments is a common Kubernetes administration task.  As examples, you might need to enable verbose logging, set an explicit value to override a default, or configure a host name or port set in a container’s arguments. In the example below, we are targeting the ‘metrics-server’ in the Kubernetes: patching container arguments array with kubectl and jq

Kubernetes: patch every array element using kubectl and jq

Below is an example using ‘kubectl patch’ to update the securityContext of a single, specific container named ‘my-init-container1’ of the ‘initContainers’ list. kubectl patch deployment my-deployment -n default –patch='{ “spec”: { “template”: { “spec”: { “initContainers”: [ { “name”: “my-init-container1”, “securityContext”: { “runAsUser”: 999 } } ] } } } }’ But ‘initContainers’ is an Kubernetes: patch every array element using kubectl and jq

Kubernetes: kustomize transformations with patchesStrategicMerge

The power of kustomize lies in its ability to transform yaml, and one of the methods for this is  patchesStrategicMerge. Where the strategic merge patch excels is in inserting elements and replacing values, allowing you to specify the desired patch using the same indentation level as the target, which makes the intended result very intuitive. Kubernetes: kustomize transformations with patchesStrategicMerge

Kubernetes: adding and removing pod template annotations using kubectl

Although ‘kubectl annotate‘ will set an annotation on a  object directly, it will not set the annotation on the more deeply nested pod template for a Deployment or Daemonset. If you want to quickly set the annotation on a pod template (.spec.template.metadata.annotations) without modifying the full manifest, you can  use the ‘patch‘ command.  As a Kubernetes: adding and removing pod template annotations using kubectl

Ubuntu: Testing the official released kernel patches for Meltdown CVE-2017-5754

The Meltdown vulnerability affects Intel and some ARM (but not AMD) processor chips and can allow unprivileged access to memory in the kernel and other processes. Canonical has committed to kernel patches to address this issue and they are now available from the both the updates and security official Ubuntu repositories. In this article, I’ll step through patching an Ubuntu: Testing the official released kernel patches for Meltdown CVE-2017-5754

Ubuntu: Testing the first candidate kernel patches for Meltdown CVE-2017-5754

The Meltdown vulnerability affects Intel and some ARM (but not AMD) processor chips and can allow unprivileged access to memory in the kernel and other processes. Canonical has committed to kernel patches to address this issue by January 9, 2018 and the first candidate kernel patches have now been released for Xenial and Trusty LTS. UPDATE Jan 11 Ubuntu: Testing the first candidate kernel patches for Meltdown CVE-2017-5754

Ubuntu: Testing the KAISER kernel patch for Meltdown CVE-2017-5754

The Meltdown vulnerability affects Intel and some ARM (but not AMD) processor chips and can allow unprivileged access to memory in the kernel and other processes.  Canonical has committed to kernel patches to address this issue by January 9, 2018. A paper coming out of Graz University of Technology in Austria and written by Daniel Gruss, Moritz Lipp, Michael Ubuntu: Testing the KAISER kernel patch for Meltdown CVE-2017-5754

Ubuntu: HWE Hardware Enablement Stacks, LTS, and the Kernel

If you installed (or upgraded to) a later Ubuntu point release:  >= 12.04.2, >=14.04.2, or >=16.04.2, you may now be wondering why the system is warning you upon every login that you will no longer receive security updates. WARNING: Security updates for your current Hardware Enablement Stack ended on 2016-08-04:  * http://wiki.ubuntu.com/1404_HWE_EOL Although the first Ubuntu: HWE Hardware Enablement Stacks, LTS, and the Kernel