Atlassian DC Helm charts 1.18 onwards support Red Hat OpenShift. More details: https://community.atlassian.com/t5/Data-Center-articles/Atlassian-Data-Center-Helm-Charts-Now-Support-Red-Hat-OpenShift/ba-p/2623049

Target Helm charts release - 1.18.

Hello Contributors,

Appreciate the patience with regards to making Jira DC deployable on Openshift platform we are in the process of evaluating this and will have more updates for you in the next few weeks.

Thanks again for your continued support and valuable feedback.

Regards
AD
PM in Data Centre

Hi Guys,  I didn't get why we are differentiating between k8s and Openshift in this context ? 

If it's supported in k8s, it's intuitively supported in Openshift.

Consider k8s as an OS ... k8s is the OS of vanilla k8s , of Tanzu , of Openshift, of Rancher,...etc . isn't it ?

Data Center has officially released Atlassian DC container images and helm charts for deploying DC products (Jira, Confluence, Bitbucket and Bamboo) on the K8s cluster on Sep 2021. https://atlassian.github.io/data-center-helm-charts/ 

We use Helm Chart templates to give you a cloud-agnostic method no matter you choose to do it on-prem or on EKS, AKS, GKE or other hosted K8s of your choice. That also means, in some cases, you need to configure and modify the templates to suit your needs, and we do provide some examples here. https://atlassian.github.io/data-center-helm-charts/examples/EXAMPLES/

Although we don't support the Openshift platform officially, we provide some advice on how to modify https://atlassian.github.io/data-center-helm-charts/platforms/OPENSHIFT/

We will keep gathering interests on official support Openshift platform.

Bump to have support for K8s, We are looking at deployment using GitOps model if possible, even if helm is supported we can extract the deployment  files using kustomize to update as needed

Hello,
I'm asked by (@Tiago Vitorino) to give as mutch information to this topic as I could... 
We, in our company, running Jira DataCenter ON-PREM with currently 500 users on two different nodes (crowing). We also made the decision to setup confluence. For now we want to have a very limited pilot project to learn how we could integrate confluence in our processes. We also have a Openshift instance running we want to use.
The plan was actually to setup confluence(-server for now) within Openshift. Therefore we found the following helm scipts https://mox.sh/helm/charts/confluence-server/. But we are struggling with the setup. We don't achief a stable setup. So we decided to cancle this idea and do the setup in a classic way.

WHY we do this:

• In a company with our size (>45000 employes) we need to care about the support topics. In the planned way we do not have any support for the Docker images (as stated here https://confluence.atlassian.com/doc/confluence-installation-guide-135681.html), but also no support for the setup on Openshift itself (helm scripts)
• We need to care about security concerns. We made the experiance, that we need to give the role running the confluence pods, special access rules. Openshift is more limited than Kubernetes regarding security, thats why we use Openshift...
• The solution could be to ask a Solution Partner for the setup, but in our case we do not want to implement a solution on our own, we want a well known an proven implementation. So we are safe for any unexpected support case or changes in the future.

WHAT we need:

• Fully support for the Docker images
  • security awareness, probably not hosting it at dockerhub but on e.g. quay.io. This is an more professional way to expose images, because of the security scans.
  • running Docker container with non root (limited permissions) based on the official supported images from Atlassian
• A fully support for Kubernetes/Openshift platforms
  • to manage our resources (e.g. kill a node on the weekend if it is not necessary)
  • to automatically build an HA Environment
  • documented needed permissions
  • documented architecture
  • documented way for scaling up/down
• A very common supported installation way. So we do not develop our own and struggling with future changes...

WHAT we want:

• a less monolythic image
  • so we are able the manage our resources in detail. Running microservices allows us to double resource where needed but safe resources where not needed but be still in an HA environment.
  • using standard deployments, e.g. ElasticSearch
• an Operator for Openshift to setup a fully supported HA environment by executing an item in the markedplace to safe as mutch setup time as possible and reduce the risk of errors during setup but be on an standard configuration which is supported
• or an fully supported deployment based on good old kubernetes deployment scripts or based on helm or ansible or what ever... at least a guide to do this, where I could get support...

Long story, but I hope you may understand the idea behind and why we want what we want

Bump - availability for both OpenShift and K8S interest us highly.

Hi,

I'd like for this to be bumped and some timescales on Kubernetes support please ? I want to migrate my instances to K8's but am put off by the lack of support.

When will this be available?