$ oc get pod <POD_NAME> -o json | jq -r '.spec.volumes[] | select(.name=="config").secret.secretName'
Related OpenShift documentation is Updating a cluster within a minor version by using the CLI.
Available upgrades are managed by https://github.com/openshift/cincinnati-graph-data/tree/master/channels.
Individual graph edges can be blocked by https://github.com/openshift/cincinnati-graph-data/tree/master/blocked-edges.
KCS that is dynamically built and communicates why edges are blocked: https://access.redhat.com/node/6103381
$ kubectl get pods -o json
$ kubectl get pods -o jsonpath='{@}'
$ kubectl get pods -o jsonpath='{.items[0]}'
$ kubectl get pods -o jsonpath='{.items[0].metadata.name}'
$ kubectl get pods -o jsonpath="{.items[*]['metadata.name', 'status.capacity']}"
$ kubectl get pods -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.startTime}{"\n"}{end}'
$ kubectl get pods -o jsonpath='{.items[*].status.podIP}'
apiVersion: rbac.authorization.k8s.io/v1 | |
kind: ClusterRole | |
metadata: | |
name: mount-nfs | |
rules: | |
- apiGroups: | |
- security.openshift.io | |
resources: | |
- securitycontextconstraints | |
verbs: |
apiVersion: v1 | |
kind: Pod | |
metadata: | |
name: nfs-client | |
spec: | |
containers: | |
- image: quay.io/noseka1/openshift-toolbox:basic | |
name: openshift-toolbox | |
volumeMounts: | |
- name: nfs-volume |
Install the operator using the Manual approval strategy, see the attached screenshot.
An install plan has been created but not executed as it has not been approved:
oc get installplan -n openshift-logging
NAME CSV APPROVAL APPROVED
install-dq68d clusterlogging.4.5.0-202007012112.p0 Manual false
These instructions can be run from a command line using oc
authenticated to the target cluster. They were derived from the OpenShift documentation for installing the Cluster Logging Operator using the CLI. Here is an ansible playbook that was also used during testing.
Create a file named logging_namespace.yml
with the following content:
# dump all forwarded input to stdout | |
<source> | |
@type forward | |
bind 0.0.0.0 | |
port 24224 | |
</source> | |
<source> | |
@type forward |
The corporate DNS server that is outside of our control doesn't handle AAAA queries properly. When sent a AAAA query, the DNS server doesn't respond. A properly working DNS server returns NOERROR, ANSWER: 0, if there is no AAAA record for a given name. Misconfigured DNS server doesn't send any response.
In an IPv6-enabled environment, the client tries to resolve both A and AAAA addresses. If the DNS server doesn't send any reply, the client repeats the query and eventually times out. Only after the AAAA query times out, the client will use the A address. Waiting for the timeouts renders utilities like curl, kubectl, oc, ... and others unusable.