Repository navigation
Open
Labels
Description
What steps did you take:
We install some Cronjobs in remote clusters via the kapp-controller.
Our Setup: oci-bundle -> appCR -> kapp-controller -> remote cluster
What happened:
We updates spec.jobTemplate.spec.template.spec.initContainers[0] i added .securityContext.runAsUser
But the controller did not find the change, and said no diffs.
For testing purpose we did the same with spec.jobTemplate.spec.template.spec.containers[0], which just worked fine
What did you expect:
Cronjob gets updated
Anything else you would like to add:
[Additional information that will assist in solving the issue.]
Environment:
K8S 1.31.1
Kapp-controller: v0.53.1
kbld.k14s.io/images:
- origins:
- local:
path: /home/runner/work/kapp-controller/kapp-controller
- git:
dirty: true
remoteURL: https://github.com/carvel-dev/kapp-controller
sha: 00aa728d6823620c03e3f4917cd565119b17c7d2
tags:
- v0.53.1
url: ghcr.io/carvel-dev/kapp-controller@sha256:da1ac76b07c0961ec0a1573615cb8c121fd0a4c443a0bb7f73780242d05161f0
That is the used Template for the bundle:
#@ load("@ytt:data", "data")
#@ if data.values.k8s_version.startswith("v1.31."):
---
apiVersion: batch/v1
kind: CronJob
metadata:
name: etcd-backup-restic
namespace: kube-system
spec:
concurrencyPolicy: Forbid
failedJobsHistoryLimit: 1
schedule: '0,30 * * * *'
successfulJobsHistoryLimit: 0
suspend: false
jobTemplate:
spec:
template:
spec:
hostNetwork: true
dnsPolicy: ClusterFirstWithHostNet
nodeSelector:
node-role.kubernetes.io/control-plane: ""
tolerations:
- key: node-role.kubernetes.io/control-plane
effect: NoSchedule
operator: Exists
- key: node-role.kubernetes.io/master
effect: NoSchedule
operator: Exists
restartPolicy: OnFailure
volumes:
- name: etcd-backup
emptyDir: {}
- name: host-pki
hostPath:
path: /etc/kubernetes/pki
initContainers:
- name: snapshoter
image: #@ data.values.oci_registry_1 + "/bitnami/etcd:3.5.16"
securityContext:
runAsUser: 0
imagePullPolicy: IfNotPresent
command:
- /bin/sh
- -c
- |-
set -euf
mkdir -p /backup/pki/kubernetes
mkdir -p /backup/pki/etcd
cp -a /etc/kubernetes/pki/etcd/ca.crt /backup/pki/etcd/
cp -a /etc/kubernetes/pki/etcd/ca.key /backup/pki/etcd/
cp -a /etc/kubernetes/pki/ca.crt /backup/pki/kubernetes
cp -a /etc/kubernetes/pki/ca.key /backup/pki/kubernetes
cp -a /etc/kubernetes/pki/front-proxy-ca.crt /backup/pki/kubernetes
cp -a /etc/kubernetes/pki/front-proxy-ca.key /backup/pki/kubernetes
cp -a /etc/kubernetes/pki/sa.key /backup/pki/kubernetes
cp -a /etc/kubernetes/pki/sa.pub /backup/pki/kubernetes
etcdctl snapshot save /backup/etcd-snapshot.db
env:
- name: ETCDCTL_API
value: "3"
- name: ETCDCTL_DIAL_TIMEOUT
value: 3s
- name: ETCDCTL_CACERT
value: /etc/kubernetes/pki/etcd/ca.crt
- name: ETCDCTL_CERT
value: /etc/kubernetes/pki/etcd/healthcheck-client.crt
- name: ETCDCTL_KEY
value: /etc/kubernetes/pki/etcd/healthcheck-client.key
- name: ETCD_HOSTNAME
valueFrom:
fieldRef:
fieldPath: spec.nodeName
volumeMounts:
- mountPath: /backup
name: etcd-backup
- mountPath: /etc/kubernetes/pki
name: host-pki
readOnly: true
containers:
- name: uploader
image: #@ data.values.oci_registry_2 + "/restic/restic:0.17.1"
imagePullPolicy: IfNotPresent
command:
- /bin/sh
- -c
- |-
set -euf
restic snapshots -q || restic init -q
restic backup --tag=etcd --host=${ETCD_HOSTNAME} /backup
restic forget --prune --group-by tag --keep-daily 3 --keep-last 48
env:
- name: ETCD_HOSTNAME
valueFrom:
fieldRef:
fieldPath: spec.nodeName
- name: RESTIC_REPOSITORY
value: #@ "s3:" + str(data.values.s3_endpoint) + "/" + str(data.values.bucket_name)
- name: RESTIC_PASSWORD
valueFrom:
secretKeyRef:
name: s3-restic-credentials
key: restic_password
- name: AWS_DEFAULT_REGION
value: #@ str(data.values.default_region)
- name: AWS_ACCESS_KEY_ID
valueFrom:
secretKeyRef:
key: AWS_ACCESS_KEY_ID
name: s3-restic-credentials
- name: AWS_SECRET_ACCESS_KEY
valueFrom:
secretKeyRef:
key: AWS_SECRET_ACCESS_KEY
name: s3-restic-credentials
volumeMounts:
- mountPath: /backup
name: etcd-backup
#@ end
Metadata
Metadata
Assignees
Labels
Type
Projects
- StatusShow more project fieldsTo Triage
Activity
100mik commentedon Oct 24, 2024
To narrow down on the issue, what happens when you run something along the lines of
ytt -f config | kbld -f - | kapp deploy - f - -a <app name>Can you reproduce this using the CLIs as well?qeqar commentedon Oct 24, 2024
Tried it with kapp too, same thing.
But no runs as in cronjob
100mik commentedon Oct 24, 2024
Definitely suspicious, I am going to try and mock this, but looks like a rebase rule at play.
I do not think we have default rebase rules that would do this. However, could you confirm that you do not have any additional rebase ules that are causing this?
mamachanko commentedon Oct 24, 2024
@100mik no custom rebase rules are involved according to @qeqar
cppforlife commentedon Oct 24, 2024
@mamachanko is there any other section of custom kapp config that might be at play? is it possible to share?
qeqar commentedon Oct 25, 2024
I can add some more files, but i don't see a place were i changed the rules.
the appCR:
We don't have any special config for the kapp-controller
And thats all.
Tell me if i should look into more special places.
mamachanko commentedon Oct 25, 2024
@qeqar this either suggests that - as you mentioned - kapp(-controller) is dropping the change or the change is already applied. The latter might be possible, b/c kapp-controller may already have applied it.
Can you assert whether the respective
CronJobon your live cluster is really missingspec.jobTemplate.spec.template.spec.initContainers[0].securityContext.runAsUser?Use any tool of choice, but this may lead you right to it I think:
qeqar commentedon Oct 25, 2024
I looked more then once in the target cluster, and it only get added when the CronJob resource is newly created.
praveenrewar commentedon Nov 11, 2024
@qeqar Would you be able to share the output of the following?
(Just trying to ensure that there's no kapp config that might have seeped in the bundle config.)
qeqar commentedon Nov 11, 2024
@praveenrewar
praveenrewar commentedon Nov 15, 2024
@qeqar Sorry, missed the notification, could you also share all the files present in the bundle? Are these two resources that you shared above the only ones in the bundle?
qeqar commentedon Nov 18, 2024
@praveenrewar yes it will render only the cronjob and the secret.
I have the schemal and default.yaml and bundle.yaml
Thats all.
And i use these to command to create/upload the bundle:
ytt -f bundle/templates -f bundle/schemas -f bundle/values $(LOCAL_TEST_VALUES) --data-value k8s_version=v$$k8sver ; done | kbld --imgpkg-lock-output bundle/.imgpkg/images.yml -f -imgpkg push -b ${REPO_URL}/gks/bundles/${BUNDLE_NAME}:v${RP_VERSION_SHORT} -f ./bundle --registry-password="${DEPLOY_PASSWORD}" --registry-username="${DEPLOY_USER}"that is all!
praveenrewar commentedon Nov 18, 2024
That is indeed a bit weird, because I am not able to reproduce the issue with a CronJob and I can't think of any other way kapp rebase rules could have been passed.
Could you try deleting the App, and then deploying the resource directly using kapp? (i.e. run the following command twice, first without the securityContext and then with it)