March 19, 2018 | Written by: Michael Elder
Categorized: Events | Hybrid Deployments
By the way, if you’re at Think 2018 in Las Vegas, please stop by one of my sessions and introduce yourself! I’d love to hear about what business problems you’re tackling and discuss how we can help.
- Kubernetes version 1.9: In our latest drop, we bring you Kubernetes 1.9 with improvements in reliability and graduated versions of new versions the Workload API. We also now package Docker 17.09 to ensure ease of setup of your boot node. As always, the installer will install and configure Docker on all nodes in the cluster, for all supported operating systems and architectures.
Security: Security remains one of our top priorities. We have simplified the creation of new Teams by supporting individual user import. Now specific users can be added from LDAP directly to any team.
We also had the frequent request for first-class support of LDAP User Groups as security principles. Now, entire user groups can be assigned to a team. No membership information is retained in IBM Cloud Private, avoiding the need for complicated user synchronization as roles changes or users are offboarded from LDAP.
We have also introduced tighter security controls around Helm Repositories. Individual Helm Repos can be added or removed from teams just as you can do with namespaces. In a near-team update, we’ll also support management of individual helm charts on a per-team basis as well.
Our original security model retained all cluster management functions under a single user. We have added a new role, Cluster Administrator, which can be assigned to any member of a team. Now Cluster Administrators are able to perform tasks like add new teams or modify the global Helm repository.
We have also graduated Vulnerability Advisor from Tech Preview to General Availability, meaning that it’s now fully supported for production workloads. When you configure Vulnerability Advisor, we recommend that you dedicate specific capacity for the analyzers as you do for management nodes already. Images and running containers are scanned from a database of known risks and problems are identified along with a relative severity.
Catalog enhancements: We now support Open Service Broker API v2.13. You can now manage your Open Service Brokers from the web console. Service Brokers are deployed as Helm Charts, which allows them to register new Service Classes. Service Classes can further be invoked from the catalog to create available services for apps running on the platform. We will soon be able to bridge these Service Classes into apps running on Cloud Foundry. For now, you can provision services and then create user-defined services in Cloud Foundry. In addition to the existing command line support for Open Service Brokers, information about Service Classes and Service Instances is now exposed in the web user interface as well.
Our Image Registry now exposes additional actions to adjust the scope of images (per-namespace or global) and to perform image clean up or removal.
Helm charts provide an open format for packaging and delivering content for Kubernetes. As new versions of charts are available, IBM Cloud Private will automatically detect new versions and highlight existing releases that are eligible for an upgrade. Whether it’s your own custom Helm charts or middleware content from our community or commercial catalog, you’ll be able to upgrade or rollback to your version of choice in just a few clicks.
We have also brought additional security controls to enforce access control for Helm charts deployed into your cluster. For now, we deliver an enhanced Helm CLI binary which applies additional authorization checks as part of your Helm deploy. The new binary is 100% compatible with all community options, and brings additional verification for IBM Cloud Private. We will be working with the community to upstream these enhancements as well.
Cloud Foundry: Our Cloud Foundry support has brought the ability to apply your own customizations, an often requested feature for existing customer if IBM Bluemix Local. Now, you can integrate your own Bosh packages with their custom parameters, and those changes will be automatically applied to your CF environment.
We also continue to integrate the operational control planes across Kubernetes and Cloud Foundry, with new dashboards and exporters for Cloud Foundry metrics integrated directly into Grafana and the ELK stack running on IBM Cloud Private’s Kubernetes environments. Now, health metrics and logs from both Kubernetes and Cloud Foundry platforms, in addition to apps running on both platforms, are centrally available.
We have also introduced support for CF isolation segments and availability zones as well. Now when you configure your CF environment, you will be able to deploy multiple isolation segments and availability zones to ensure that your CF apps are properly distributed in the event of a zone failure.
Networking: Exposing services running on an IBM Cloud Private cluster in Kubernetes just got much easier for F5 BIGIP users! We now enable you to configure an F5 BIGIP Virtual Server directly from Kubernetes Services exposed in your cluster. As pods are dynamically added or removed, the routing list for the Virtual Server is kept up to date almost immediately.
Based on customer requests, we have enhanced the support for external load balancers for all management services in the cluster. You may now configure Elastic Load Balancers or other reverse proxies in the network route to the cluster and forego the high availability configurations driven by ucarp.
In addition, you can now customize the trusted, recognized Uniform Resource Locators (URLs) used for all management services for the built-in Open ID Connect (OIDC) providers. In some environments where dynamic addresses or ports were exposed in front of the known web console address, users were unable to properly authenticate with the system. The need for trusted OIDC clients is driven by security requirements from the OAuth2 protocol. With enhancements in WebSphere Liberty’s OIDC support, you may now define regular expressions for a registered, trusted endpoint for trusted hostnames and port ranges.
Cluster Management for Kubernetes: We now include packages for the Docker runtime for the boot node, in addition to all cluster nodes. Some users found the lack of a built-in package problematic; now you can leverage our Docker runtime package for all supported operating systems and architectures.
Workloads are able to take advantage of cluster elasticity with ease for both Kubernetes and Cloud Foundry, but what if you’d like to dynamically scale your Kubernetes cluster? Now you can use the built-in command line to dynamically add worker nodes on both OpenStack and VMWare. As always, you can integrate existing systems on bare metal or your cloud infrastructure of choice at any time after installation.
Metering: For cluster operators, understanding the utilization of your cluster resources is critical for budget and anticipating required growth. Our metering support now supports capped processor, processor usage, and memory usage for workloads on the platform. IBM middleware workloads are automatically recognized to understand licensing utilization and availability.
We have also introduced support for utilization showback per scope (such as a Kubernetes namespace), so you can understand how much capacity is in use by each of your consumers.
We have delivered a number of new entries in the IBM Cloud Private catalog, including:
Along with updates for many more charts, including IBM WebSphere, IBM Db2, Jenkins, a built-in Web Terminal, and others.