Skip to content

Instantly share code, notes, and snippets.

@jeesmon
jeesmon / pod-exec
Created May 27, 2021 18:15
Kubernetes Pod Exec using curl
curl -k \
--http1.1 \
-H "Sec-WebSocket-Key: SGVsbG8sIHdvcmxkIQ==" \
-H "Sec-WebSocket-Version: 13" \
-i \
-N \
-H "Connection: Upgrade" \
-H "Upgrade: websocket" \
-H 'Authorization: Bearer <TOKEN>' \
"<API_SERVER>/api/v1/namespaces/<namespace>/pods/<pod_name>/exec?command=ls&command=-l&stdin=true&stdout=true&stderr=true"
@jeesmon
jeesmon / openshift-sm-additional-ingress-gateway.md
Last active September 11, 2021 13:20
OpenShift ServiceMesh Additional Ingress Gateway

Steps

  • Edit ServiceMesh Controlplane (SMCP) default
spec:
....
  gateways:
    additionalIngress:
      istio-internal-ingressgateway:
@jeesmon
jeesmon / find-ownerreferences.sh
Created September 30, 2021 19:41
Find ownerReferences of pods in OpenShift cluster
oc get po -A -o wide | grep {filter} | while read a b c;
do
r=$(echo -n $a $b; oc get po -n $a $b -o jsonpath='{range .metadata.ownerReferences[*]} {.kind} {.name}{"\n"}{end}');
echo $r;
if [[ $r == *"ReplicaSet"* ]];
then echo $r | while read a b c d;
do
oc get rs -n $a $d -o jsonpath='{range .metadata.ownerReferences[*]} {.kind} {.name}{"\n"}{end}';
done;
fi;
@jeesmon
jeesmon / copy-kube-secret
Created October 28, 2021 18:26
Copy and apply kubernetes Secret from one namespace to another
kubectl get secret <name> -n <namespace> -o json \
| jq '.metadata.name="<new_name>"|.metadata.namespace="<new_namespace>"' \
| kubectl apply -f -
@jeesmon
jeesmon / resources-owned-by-crd.md
Created January 18, 2022 14:30
Find all resources owned by a CRD Kind
kubectl api-resources --no-headers | \
awk '{print $1}' | \
xargs -I '{}' kubectl get '{}' --all-namespaces -o json 2>/dev/null | \
jq '.items[] | \
select((.metadata.ownerReferences // [])[] | \
select(.kind == "YourCRD"))'

Credits: Oleg Matskiv

If you are creating a standalone go library for your operator and have types that are used in your operator CRD spec/status, you will see that you need code-generation to generate DeepCopy and DeepCopyInto methods for your types. For API types in your operator, make generate will do that for you automatically using controller-tools. But for your library project that is not using controller-tools, you can do the same code generation using github.com/kubernetes/code-generator.

An example is here: https://github.com/jeesmon/operator-utils/blob/main/Makefile#L14-L20

Steps:

You can easily enable monitoring for your projects in OpenShift if your workload exposes a metrics endpoint that can be scraped by prometheus. For example, operator you develop using operator-sdk adds an endpoint with lots of useful metrics by deault. You can query them in OpenShift web console if you enable monitoring for user-defined projects.

To enable, edit cluster-monitoring-config ConfigMap in openshift-monitoring namespace and add the following under data

data:
  config.yaml: |
    enableUserWorkload: true

If you use go 1.17 in go.mod and run go mod tidy, you will see a second require block with indirect dependencies. Few things changed in 1.17 for dependency graph. More details here: https://go.dev/doc/go1.17#go-command

Also, few useful commands to manage dependencies

go mod tidy # fix up modules
go mod why -m <module> # shows where this module is used from main module
go mod graph # shows module requirement graph
go list -m all # list all dependencies
go list -m -u -versions -json <module> # shows versions of a module

More advanced use case, but if you ever wanted to write operators to manage lifecycle of multiple kube clusters, cluster-api is something you want to look into: https://cluster-api.sigs.k8s.io

Goals:

  • To manage the lifecycle (create, scale, upgrade, destroy) of Kubernetes-conformant clusters using a declarative API.
  • To work in different environments, both on-premises and in the cloud.
  • To define common operations, provide a default implementation, and provide the ability to swap out implementations for alternative ones.
  • To reuse and integrate existing ecosystem components rather than duplicating their functionality (e.g. node-problem-detector, cluster autoscaler, SIG-Multi-cluster).
  • To provide a transition path for Kubernetes lifecycle products to adopt Cluster API incrementally. Specifically, existing cluster lifecycle management tools should be able to adopt Cluster API in a staged manner, over the course of multiple releases, or even adopting a subset of Cluster API.