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.
Please note that Jira is actively being worked on to address these issues in the coming releases.
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.
There are a number of known limitations relating to Bamboo Data Center, these are documented below.
Until this issue has been resolved, the recommended approach for deploying Bamboo server is using an
unattended approach. That is, providing values to all those properties labeled as
UNATTENDED-SETUP within the
values.yaml. This has the added benefit of eliminating any manual intervention (via the setup wizard) required for configuring Bamboo post deployment.
It should also be noted that the property,
bamboo.unattendedSetup should be set to
true (current default value) for this to work.
Cluster size ¶
At present Bamboo Data Center utilizes an active-passive clustering model. This architecture is not ideal where K8s deployments are concerned.
1 pod clusters only
At present, Bamboo server cluster sizes comprising only
1 pod is the only supported topology for now.
Server and agent affinity ¶
The Bamboo server and Bamboo agents must be deployed to the same cluster. You cannot have Bamboo agents in one cluster communicating with a Bamboo server in another.
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
/status endpoints become un-usable when performing an export or import of large datasets.
For large Bamboo instances we recommend using native database and filesystem backup tools instead of the built in export / import functionality that Bamboo provides. See the migration guide for more details.
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.
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.