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 ¶
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
bamboo: jmsService: enabled: true type: (LoadBalancer|NodeIP)
Security and performance considerations
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
/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.
LoadBalancer service type ¶
If a Kubernetes cluster has multiple cluster nodes and Crowd
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.