Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ES restart after encrypting etcd data on openshift container platform 4.12 #7753

Open
patrisaru opened this issue Apr 26, 2024 · 1 comment
Labels

Comments

@patrisaru
Copy link

After performing etcd encryption on a cluster with openshift self managed (onprem) 4.12, we have detected that every seven days the api server performs a key rotation that seems to be noticeable to the elasticsearch operators. This causes the ES operators to trigger a restart of the elasticsearch pods.
According with the redhat documentation https://docs.openshift.com/container-platform/4.12/security/encrypting-etcd.html seems that the encrytion has affect to some objects like secrets or configmap...We are understanding that the ES operator is sensitive to this process and cause a restart on the ES pods...

Is this the expected behaviour? Could we avoid this behaviour?

Here is the ES configuration:


apiVersion: elasticsearch.k8s.elastic.co/v1beta1
kind: Elasticsearch
metadata:
name: elastic-elasticsearch
spec:
version: 7.10.1
nodeSets:
######################################################

MASTER NODE

######################################################

  • name: master-node
    count: 1
    config:
    node.roles: ["master","data","ingest"]
    node.store.allow_mmap: true
    xpack.monitoring.enabled: true
    xpack.monitoring.collection.enabled: true
    podTemplate:
    metadata:
    name: elastic-elasticsearch
    spec:
    initContainers:
    - name: sysctl
    securityContext:
    privileged: true
    command: ['sh', '-c', 'sysctl -w vm.max_map_count=262144']

    containers:
    - name: elasticsearch
      env:
      - name: ES_JAVA_OPTS
        value: "-Xms1g -Xmx1g  -Dlog4j2.formatMsgNoLookups=true"
      resources:
        requests:
          memory: 1024Mi
          cpu: 256m
        limits:
          memory: 4096Mi
          cpu: 1024m
    

http:
service:
spec:
type: ClusterIP

Thanks in advance!

@botelastic botelastic bot added the triage label Apr 26, 2024
@barkbay
Copy link
Contributor

barkbay commented Jun 10, 2024

Are you using secure settings? You might be affected by #7842, fixed in the next version.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants