Limitations ¶

Product limitations ¶

We haven't changed our Data Center applications' architecture to support Kubernetes. So, as is with all our Data Center products, the following limitations still exist:

• We don't support horizontal or vertical autoscaling in our products. Read about Product scaling.
• More pods doesn't mean that the application will be more performant.
• We still have session affinity, so you will need to have a network setup that supports that.

Jira and horizontal scaling ¶

At present there are issues relating to index replication with Jira when immediately scaling up by more than 1 pod at a time.

• Index replication service is paused indefinitely
• Automatic restore of indexes will fail

Although these issues are Jira specific, they are exasperated on account of the significantly reduced startup times for Jira when running in a Kubernetes cluster. As such these issues can have an impact on horizontal scaling if you don't take the correct approach.

Bamboo ¶

There are a number of known limitations relating to Bamboo Data Center, these are documented below.

Deployment ¶

With Bamboo DC 8.1 deployments to K8s using the Helm charts are now possible. This release does however contain an issue where partial unattended deployments to K8s do not work.

Cluster size ¶

At present Bamboo Data Center utilizes an active-passive clustering model. This architecture is not ideal where K8s deployments are concerned.

Server and agent affinity ¶

It is preferable that the Bamboo server and agents are be deployed to the same cluster due to security and performance reasons. If agents are deployed outside the Kubernetes cluster, you need to expose Bamboo server JMS port as LoadBalancer or NodeIP:

bamboo:
  jmsService:
    enabled: true
    type: (LoadBalancer|NodeIP)

If Bamboo server JMS port is exposed, it is highly recommended that you either allow access to it for Bamboo agents CIDR only (inbound security group rules if on AWS), and/or secure remote agent by configuring SSL for AMQ.

Deploying Bamboo agents to the same cluster with the server or at least to the same region/availability zone/datacenter is highly recommended to avoid performance and latency issues.

Bamboo to Cloud App Link ¶

When configuring application links between Bamboo server and any Atlassian Cloud server product, the Bamboo server base URL needs to be used. See public issue for more detail.

Import and export of large datasets ¶

At present there is an issue with Bamboo where the /server and /status endpoints become un-usable when performing an export or import of large datasets.

The Bamboo Helm chart does however provide a facility that can be used to import data exports produced through Bamboo at deployment time. This can be used by configuring the Bamboo server values.yaml appropriately i.e.

import:
  type: import
  path: "/var/atlassian/application-data/shared-home/bamboo-export.zip"

Using this approach will restore the full dataset as part of the Helm install process.

Crowd ¶

LoadBalancer service type ¶

If a Kubernetes cluster has multiple cluster nodes and Crowd service.type is LoadBalancer, Crowd pods may receive client requests from different cluster node IPs. This will cause session invalidation in the client browser, which is a security feature of Crowd. You can resolve it by either:

• Unticking "Require consistent client IP address" in Session configuration or
• Configuring AWS LoadBalancer with session affinity by annotating a service. You can find more details in AWS LoadBalancer documentation.

Platform limitations ¶

These configurations are explicitly not supported, and the Helm charts don’t work without modifications in these environments:

• Istio infrastructure
  • Due to several reasons, Istio is imposing networking rules on every workload in the Kubernetes cluster that doesn't work with our deployments.
  • The current recommendation is to create an exemption for our workloads if Istio is enabled in the cluster by default.