<p>I am preparing a helm chart for pilosa. After installing the chart (or while creating the deployment),
the pilosa pod enters to a CrashLoopBackOff.</p>
<p>This is the rendered YAML file for the k8s deployment.</p>
<pre><code># Source: pilosa/templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: RELEASE-NAME-pilosa
  labels:
    helm.sh/chart: pilosa-0.1.0
    app.kubernetes.io/name: pilosa
    app.kubernetes.io/instance: RELEASE-NAME
    app.kubernetes.io/version: &quot;1.16.0&quot;
    app.kubernetes.io/managed-by: Helm
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: pilosa
      app.kubernetes.io/instance: RELEASE-NAME
  template:
    metadata:
      labels:
        app.kubernetes.io/name: pilosa
        app.kubernetes.io/instance: RELEASE-NAME
    spec:
      imagePullSecrets:
        - name: my-cr-secret
      serviceAccountName: default
      securityContext:
        {}
      initContainers:
        - command:
          - /bin/sh
          - -c
          - |
            sysctl -w net.ipv4.tcp_keepalive_time=600
            sysctl -w net.ipv4.tcp_keepalive_intvl=60
            sysctl -w net.ipv4.tcp_keepalive_probes=3
          image: busybox
          name: init-sysctl
          securityContext:
            privileged: true
      containers:
        - name: pilosa
          securityContext:
            {}
          image: &quot;mycr.azurecr.io/pilosa:v1.4.0&quot;
          imagePullPolicy: IfNotPresent
          command:
            - server
            - --data-dir
            - /data
            - --max-writes-per-request
            - &quot;20000&quot;
            - --bind
            - http://pilosa:10101
            - --cluster.coordinator=true
            - --gossip.seeds=pilosa:14000
            - --handler.allowed-origins=&quot;*&quot;
          ports:
            - name: http
              containerPort: 10101
              protocol: TCP
          livenessProbe:
            httpGet:
              path: /
              port: http
          readinessProbe:
            httpGet:
              path: /
              port: http
          volumeMounts:
            - name: &quot;pilosa-pv-storage&quot;
              mountPath: /data
          resources:
            {}
      volumes:
      - name: pilosa-pv-storage
        persistentVolumeClaim:
          claimName: pilosa-pv-claim
</code></pre>
<p>When checked the reason for that i found:</p>
<pre><code>$ kubectl describe pod pilosa-57cb7b8764-knsmw
.

.

Events:
  Type     Reason     Age                From               Message
  ----     ------     ----               ----               -------
  Normal   Scheduled  48s                default-scheduler  Successfully assigned default/pilosa-57cb7b8764-knsmw to 10.0.10.3
  Normal   Pulling    47s                kubelet            Pulling image &quot;busybox&quot;
  Normal   Pulled     45s                kubelet            Successfully pulled image &quot;busybox&quot;
  Normal   Created    45s                kubelet            Created container init-sysctl
  Normal   Started    45s                kubelet            Started container init-sysctl
  Normal   Pulling    45s                kubelet            Pulling image &quot;mycr.azurecr.io/pilosa:v1.2.0&quot;
  Normal   Pulled     15s                kubelet            Successfully pulled image &quot;mycr.azurecr.io/pilosa:v1.2.0&quot;
  Normal   Created    14s (x2 over 15s)  kubelet            Created container pilosa
  Warning  Failed     14s (x2 over 15s)  kubelet            Error: failed to start container &quot;pilosa&quot;: Error response from daemon: OCI runtime create failed: container_linux.go:349: starting container process caused &quot;exec: \&quot;server\&quot;: executable file not found in $PATH&quot;: unknown
  Normal   Pulled     14s                kubelet            Container image &quot;mycr.azurecr.io/pilosa:v1.2.0&quot; already present on machine
  Warning  BackOff    10s                kubelet            Back-off restarting failed container
</code></pre>
<p>That means the problem is it cannot run command server :</p>
<pre><code> Error: failed to start container &quot;pilosa&quot;: Error response from daemon: OCI runtime create failed: container_linux.go:349: starting container process caused &quot;exec: \&quot;server\&quot;: executable file not found in $PATH&quot;: unknown
</code></pre>
<p>But that command is available in pilosa as specified here : <a href="https://www.pilosa.com/docs/latest/installation/" rel="nofollow noreferrer">https://www.pilosa.com/docs/latest/installation/</a></p>
<p>Can anyone help me to find a solution for this?</p>

AnjK
<p>The issue here is that Kubernetes is overriding the <code>ENTRYPOINT</code> in the Pilosa Docker image. The <code>server</code> command is actually a subcommand of <code>pilosa</code>, which works because of how the Pilosa Dockerfile defines the command:</p>
<pre><code>ENTRYPOINT [&quot;/pilosa&quot;]
CMD [&quot;server&quot;, &quot;--data-dir&quot;, &quot;/data&quot;, &quot;--bind&quot;, &quot;http://0.0.0.0:10101&quot;]
</code></pre>
<p>Because you are using the <code>command:</code> declaration, it overrides both the <code>ENTRYPOINT</code> and the <code>CMD</code> when invoking the container.</p>
<p>I think the simple solution is to replace <code>command:</code> with <code>args:</code>, and I believe k8s will no longer override the <code>ENTRYPOINT</code>. Or you could instead add <code>/pilosa</code> to the front of the command.</p>
<p>You may also take a look at this Pilosa helm chart, which is unmaintained but might work for you. Note that it uses a StatefulSet instead of a Deployment, which should fit Pilosa better: <a href="https://github.com/pilosa/helm" rel="nofollow noreferrer">https://github.com/pilosa/helm</a></p>
