If you’re a member of our Slack Team, you’ve probably seen a bunch of messages in the containers channel where GitHub issues have been getting closed. There’s a good reason for that! We just released the first beta for the next major Trident release!
You might be wondering what triggers a beta release for Trident. We are constantly working on Trident, adding features, fixing bugs, and generally adding code to make things better in the short and long term. So, why a beta now?
Our rule of thumb regarding releases works like this:
- Release a beta (e.g. 18.07 Beta 1) when there is new functionality which we want you to have access to, possibly before it’s ready for production, and sometimes we just want to get something super cool or important out as soon as possible
- Release a fix for an existing version (e.g. 18.04.1) when we fix critical bugs for the current version, but don’t have any new features to preview in a beta
Our GitHub presence is very important to this process. It’s how we know what is important to you and how we know what you’re interested in for both bugs and new features. Our CI system is hard at work finding bugs and errors as development happens, but that doesn’t mean we find everything. So, please keep letting us know what matters to you using GitHub and Slack!
Without further delay, let’s look at Trident 18.07 beta 1!
Adding CSI Support to Trident
The Container Storage Interface, a.k.a. CSI, is an emerging standard which will provide a unified interface for connecting containers and storage across several different orchestrators. NetApp is, of course, a supporter of and participant in this important open source project. CSI was recently added as beta to Kubernetes 1.10, so we are releasing our alpha CSI driver for Trident.
Getting up and running with CSI in your deployment is straightforward, but there’s some important things you should know about when, and why, to use CSI versus Trident’s native integrations with Kubernetes and Docker. Most importantly, the CSI drivers are alpha, which means they are unsupported! If you’re interested in CSI functionality, we recommend using a non-production cluster to test, experiment, validate, and/or break as much as possible…and we would love to hear your feedback!
High availability is important for Trident, if it stops functioning then no new volumes will be created for PVCs being submitted by applications. Trident, and the co-deployed etcd, have always relied on Kubernetes to restart the pod in the event of a failure, e.g. anything which causes the process to end, like a node being halted. However, this didn’t cover all scenarios, such as Trident becoming unresponsive despite the process still running.
Making non-standard deployments easier
tridentctl is the deployment engine for Trident as of version 18.04, and this change greatly simplified many of the deployment tasks, making the process much easier for us to provide real-time information on what’s happening with the deployment process. We have also heard from you that the ability to customize the deployment for your environment is extremely important and needs to be simpler.
Historically, the way to customize the deployment was to modify the yaml definitions for the Trident components. This often involved some more-than-basic knowledge of both Kubernetes and Trident to ensure that everything went according to plan. This beta release introduces some new flags for the
tridentctl install command to customize the deployment:
--trident-image: provide a customized image for Trident. The default is tied to the current release, e.g. “
netapp/trident:18.07.0-beta.1“. If you have a customized Trident you could use something like “
myself/trident:custom.0“, or you could specify a particular version if desired, e.g. “
netapp/trident:18.04.0” to use a previous release.
--etcd-image: provide a customized image for etcd. Like above, this allows you to use an etcd version, and location, which meets your needs. The default version could previously be seen in the
deployment.yaml, however with this change it’s found in
These two options allow you to easily define the registry which hosts the container images. Let’s say that I have a private registry at “
registry.netapp.io” (note, this doesn’t exist!). Without modifying any yaml, I can change the location of those images using an install command which looks like this:
tridentctl install -n trident \ --trident-image=registry.netapp.io/trident:18.07.0-beta.1 \ --etcd-image=registry.netapp.io/etcd:3.2.19
Simple and easy. Doing installs for clusters without internet connectivity just got a lot easier!
More to come!
Trident 18.07 will be generally available soon, which means that we will have even more features and capabilities available for you. Be sure to watch netapp.io for release announcements in the coming weeks!