Platform9 3.0 release notes

Platform9 Managed Kubernetes:

1. Kubernetes version upgrade to 1.5.7

In this release, Platform9 Managed Kubernetes has upgraded the Kubernetes version from 1.4.9 to 1.5.7. You can find more info on this version, along with its various features, in the Kubernetes 1.5 blog. To move your cluster to use this version of Kubernetes, you should trigger the cluster upgrade as laid out in the note about upgrading clusters below. Users may need to get a compatible kubectl for this version, if their existing kubectl is not compatible with Kubernetes 1.5.7.

2. Control when you want to upgrade each Kubernetes cluster

We understand that a single, common upgrade window for all your Kubernetes clusters may not be always feasible. In this release, we are giving users the ability to upgrade individual Kubernetes clusters at the time of their choosing. However, we highly recommend users to upgrade their clusters at the earliest convenience and within 30 days of the release of new Platform9 Managed Kubernetes versions. This is primarily to ensure backward compatibility of your cluster is not compromised. Note that Kubernetes maintains backward compatibility of one previous minor release.

3. Enable Alpha APIs for Kubernetes cluster

Certain users like to experiment and gain familiarity with Alpha APIs that a Kubernetes version provides. However, these Alpha APIs are not enabled by default when a cluster is created. Starting with this release, users now have an option to enable all or specific Alpha APIs when they create a cluster. This is an advanced feature and should be used with extreme caution. We recommend not to enable such APIs on production setups. Note that Kubernetes doesn’t guarantee stability of such APIs nor compatibility of the APIs when upgrading Kubernetes versions.

4. CNI integration for Kubernetes networking

Platform9 Managed Kubernetes has moved to leverage CNI for the networking of the cluster. Flannel is still the networking backend but it is based on top of CNI now. Support for more CNI compatible networking backends will be added in the upcoming releases. Look out for future announcements in this space.

5. Bug fixes and product improvements

This release also contains a number of performance optimizations and bug-fixes that should result in a better user experience for your Platform9 cloud platform!

Platform9 Managed Kubernetes requires certain AWS capabilities be granted to the AWS cloud providers’ account. Ensure this requirement is satisfied by the IAM policies for this user. You can find the latest IAM policy file here. More details in this support article.

Known Issues:

  1. An AWS private network on which a cluster is deployed cannot be used to deploy another Kubernetes cluster. This is a known Kubernetes limitation(https://github.com/kubernetes/kubernetes/issues/35052).
  2. There are limitations when using AWS Route 53 private hosted zones with your AWS clusters:
    1. Private hosted zones are supported only when deploying into an existing VPC that has been associated with the hosted zone. Before using a private hosted zone, create a VPC and associate it with the hosted zone.
    2. Because the hosted zone is private, the API and Service FQDNs can only be resolved from within the associated VPC.

Platform9 Managed OpenStack:

1. Upgrade to Newton Release

This release upgrades Murano, Heat and Ceilometer to Newton Release. With it, all Openstack Services provided by Platform9 are based off Newton release . This release brings in a host of critical bug fixes and features. Reach out to Platform9 if you would like to try out a particular feature.

2. Metadata Service

Metadata Service enables many use cases for VM bootstrapping. It can be used in a number of ways — e.g. as a lookup for parameters of cloud-init configuration, to provide metadata for services deployed on Openstack instances, etc. Metadata service is available to accounts which currently use Neutron based networking.

3. Network Port Security

This release enables Neutron Port Security Extension. With it,  security groups can be disabled at network and port level. Security group processing by Linux kernel can post performance issues for workloads sensitive to network latency. By turning off security groups, network I/O performance of such workloads can be improved. An instance can be connected to multiple networks with or without network security, allowing for a balance of security and performance.

4. Number of available IPs

For Neutron users, number of available IPs are displayed in the network view. It provides important metric for planning out network allocation range and is a useful tool to when provisioning instances on a network.

5. Guided Tours

For new users of Openstack, guided tour provides help. It is accessible any time by clicking ‘Tour’ button at the top.

The browser you are using is outdated. For the best experience please download or update your browser to one of the following: