Gitlab does not start on kubernetes

I am in the process of running gitlab on our kubernetes cluster. I follow the document closely, create a helm chart and deployed it. Unfortunately it hangs and eventually gets restarted by kubernetes. Below are additional information:

  repository: sameersbn/gitlab
  tag: 10.6.4  
  pullPolicy: IfNotPresent

My flavor:

Database: Postgresql
Cache: Redis

And is what I am seeing in the logs:

2018-04-22 12:38:23,784 CRIT Supervisor running as root (no user in config file)
2018-04-22 12:38:23,784 WARN Included extra file "/etc/supervisor/conf.d/cron.conf" during parsing
2018-04-22 12:38:23,784 WARN Included extra file "/etc/supervisor/conf.d/gitaly.conf" during parsing
2018-04-22 12:38:23,784 WARN Included extra file "/etc/supervisor/conf.d/gitlab-workhorse.conf" during parsing
2018-04-22 12:38:23,784 WARN Included extra file "/etc/supervisor/conf.d/mail_room.conf" during parsing
2018-04-22 12:38:23,784 WARN Included extra file "/etc/supervisor/conf.d/nginx.conf" during parsing
2018-04-22 12:38:23,784 WARN Included extra file "/etc/supervisor/conf.d/sidekiq.conf" during parsing
2018-04-22 12:38:23,784 WARN Included extra file "/etc/supervisor/conf.d/sshd.conf" during parsing
2018-04-22 12:38:23,784 WARN Included extra file "/etc/supervisor/conf.d/unicorn.conf" during parsing
2018-04-22 12:38:23,800 INFO RPC interface 'supervisor' initialized
2018-04-22 12:38:23,801 CRIT Server 'unix_http_server' running without any HTTP authentication checking
2018-04-22 12:38:23,801 INFO supervisord started with pid 1
2018-04-22 12:38:24,804 INFO spawned: 'gitaly' with pid 569
2018-04-22 12:38:24,807 INFO spawned: 'sidekiq' with pid 570
2018-04-22 12:38:24,809 INFO spawned: 'unicorn' with pid 571
2018-04-22 12:38:24,811 INFO spawned: 'gitlab-workhorse' with pid 572
2018-04-22 12:38:24,813 INFO spawned: 'cron' with pid 573
2018-04-22 12:38:24,848 INFO spawned: 'nginx' with pid 574
2018-04-22 12:38:24,851 INFO spawned: 'sshd' with pid 579
2018-04-22 12:38:25,904 INFO success: gitaly entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2018-04-22 12:38:25,904 INFO success: sidekiq entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2018-04-22 12:38:25,905 INFO success: unicorn entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2018-04-22 12:38:25,905 INFO success: gitlab-workhorse entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2018-04-22 12:38:25,905 INFO success: cron entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2018-04-22 12:38:25,905 INFO success: nginx entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2018-04-22 12:38:25,905 INFO success: sshd entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2018-04-22 12:38:49,405 INFO exited: unicorn (exit status 1; not expected)
2018-04-22 12:38:50,408 INFO spawned: 'unicorn' with pid 709
2018-04-22 12:38:52,360 INFO success: unicorn entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2018-04-22 12:41:36,595 WARN received SIGTERM indicating exit request
2018-04-22 12:41:36,596 INFO waiting for sshd, gitlab-workhorse, sidekiq, cron, nginx, gitaly, unicorn to die
2018-04-22 12:41:36,597 INFO stopped: sshd (exit status 0)
2018-04-22 12:41:36,601 INFO stopped: nginx (exit status 0)
2018-04-22 12:41:36,602 INFO stopped: cron (terminated by SIGTERM)
2018-04-22 12:41:36,604 INFO stopped: gitlab-workhorse (terminated by SIGTERM)
2018-04-22 12:41:38,368 INFO stopped: unicorn (exit status 0)
2018-04-22 12:41:40,371 INFO waiting for sidekiq, gitaly to die
2018-04-22 12:41:40,579 INFO stopped: sidekiq (exit status 0)
2018-04-22 12:41:40,599 INFO stopped: gitaly (exit status 1)

I also have debug enabled and can provide that information if needed.

Start with the Helm deployment and the Kubernetes pod events alongside the provided container logs; the issue reports restarts after Unicorn exits and a later SIGTERM. Compare the chart configuration for the GitLab 10.6.4 image, PostgreSQL, and Redis with the documented deployment, then use the available debug output to identify the missing or failing setup. Done means the deployment starts and stays running, with the required configuration documented.