Monat: Februar 2020

OpenShift 4.3: Deploy Applications with Helm 3

Helm is a package manager for Kubernetes which helps users create templated packages called Helm Charts to include all Kubernetes resources that are required to deploy a particular application. Helm then assists with installing the Helm Chart on Kubernetes, and afterwards it can upgrade or rollback the installed package when new versions are available. Helm Charts are particularly useful for installation and upgrade of stateless applications given that the Kubernetes resources and the application image can simply be updated to newer versions. 
Helm 2 was based on a server-side component named Tiller which was responsible for performing Helm operations on Kubernetes clusters. Tiller was designed prior to Kubernetes role-based access control (RBAC) and although useful for single-tenant clusters, its permissive configuration could grant users a wide array of unintended permissions. Therefore it was recognised as a major security concern on multi-tenant clusters, which prevented many enterprise users from using Helm in production environments. OpenShift is an enterprise Kubernetes platform, and therefore we didn’t recommend the use of Helm 2 in production, even though it was possible to disable OpenShift security features in order for Helm 2 to be used on OpenShift.
Helm 3 was recently released as GA in the Helm community, and a major update has been removing Tiller and pivoting to a client-side architecture to address the aforementioned security concerns, removing the barrier tor using Helm in enterprise environments. OpenShift welcomes this change with open arms, and we are thrilled to announce that OpenShift 4.3 supports Helm 3 as a Tech Preview feature. It is planned for full support in upcoming releases of the platform.
Helm binaries are distributed alongside oc, odo and other OpenShift tools. 

Try out Helm 3 on OpenShift by following the instructions in OpenShift documentation.
New in Helm 3
Helm 3 introduces many large and small enhancements, a few of which are detailed below:
Tiller is gone: Helm 3 removes Tiller as the server-side component that managed Helm Charts and moves to a client-side model where all operations are performed via the Helm 3 CLI while relying on Kubernetes RBAC for authorization and security features. When a user instructs the Helm CLI to install a Helm Chart, the information about the Helm Chart is fetched from the repository, rendered on the client and then applied to Kubernetes while a record of this installation is created within the namespace (which is known as a Release). 

Releases in namespaces: Release information in Helm 3 is stored in the same namespace with a secret as the storage mechanism for the Release information
Three-way strategic merge patch: Upgrades have moved to a 3-way merge, compared to 2-way merge in Helm 2. In other words, Helm 3 takes the live state of the application resources into account in addition to the manifests in the old and new Helm Charts, and therefore preserves any manual or automatic (e.g. Horizontal Pod AutoScaler) changes that might have been applied to those resources. 
OCI Registries for charts: As an experimental feature, Helm 3 is exploring use of OCI Registries for storing and distributing charts. This would allow user to take advantage of security and provenance features that are available in these registries.
Chart validation: JSONSchema support is added to Charts in order to define a structure for the values supported by the Chart. The Helm CLI then uses this schema for validation of the values that the user provides to the Chart. 
Improved CRD support: Kubernetes Custom Resource Definition (CRD) installations are improved by treating them as special resources. Helm 3 installs the CRDs included in a Chart first, waits until they are made available on the Kubernetes API and then continues the installation of the remaining resources from the Chart.
Library charts: a class of charts called “library charts” are introduced in Helm 3 in order facilitate sharing snippets of code between charts and to encourage re-use. A library chart does not install anything and can only be defined as a dependency in other charts. 
For a more exhaustive list of updates in Helm 3, refer to the Helm 3 documentation.
Migration to Helm 3
Most existing charts are compatible with Helm 3. However, given that Helm 3 takes advantage of the Kubernetes security model while Helm 2 did not, there may be adjustments needed in order for your existing charts to be able to deploy properly without Tiller. You can read more on how to migrate from Helm 2 to Helm 3 in the Helm 3 documentation.
Next on OpenShift
For future releases of OpenShift, we are working on a tighter integration of Helm 3 into the OpenShift tools and web consoles. OpenShift embedded developer catalog, which is the central hub for all developer content, will add support for Helm Charts in addition to Operator-backed services, Templates, etc. Furthermore, integration with Helm releases is planned next in order for developers to be able to manage Helm releases directly from the OpenShift developer console.
We are very excited for the Helm 3 roadmap on OpenShift. Stay tuned…
The post OpenShift 4.3: Deploy Applications with Helm 3 appeared first on Red Hat OpenShift Blog.
Quelle: OpenShift

Driving innovation for connected cars using IBM Cloud

Cars have always been built for travel, but the experience of driving has changed dramatically over the last few decades. Today’s connected cars are not only equipped with seamless internet, but usually have a wireless local area network (WLAN) that allows the car to access data, send data and communicate with Internet of Things (IoT) technology to improve safety and efficiency and optimize performance. The car’s connectivity with the outside world provides a superior in-car experience with on-the-go access to all the features one might have at home.
Traditionally, the networks supporting this robust connectivity, unlike cars, have not been built for travel. Data is stored in a home network in a local data center, which causes latency issues as the car travels and massive amounts of data are transferred across borders. In addition, privacy legislation, like the General Data Protection Regulation (GDPR), limit the transfer of personal data outside the EU, which not only creates a poor user experience on the road, but can impact safety-related IoT insights.
We at Travelping saw an opportunity to use cloud-native technologies for networking to help the automotive industry negotiate the challenges of cross-border data management regulations and improve latency issues for auto manufacturers looking to gain real-time IoT insights.
Road less traveled is most efficient
Travelping develops carrier-grade cloud-native network functions (CNFs) that are used to design software-defined networking solutions. Using IBM Cloud infrastructure products and IBM Cloud Kubernetes Service, we created a cloud-native solution that transports data directly to the vehicles, eliminating latency issues while fulfilling requirements for GDPR. We had strict technical requirements for our IT infrastructure and chose IBM Cloud for several reasons. IBM has a global footprint, which was key for us to provide networking capabilities in the cloud and better manage compliance with GDPR and European Data Security Operation laws, which was not possible on other clouds. Many clouds in the field are what we call north-south clouds. They terminate web traffic. Our solution forwards the traffic for our mobile users — what we call east-west traffic. IBM Cloud is the only one that still allows us to transport data from node to node in a network, and not just terminate it.
For us, one of the biggest advantages in choosing IBM Cloud, in addition to all the automation and speed, is that as a team of 30 people, we can deliver globally on a cloud platform that is deployed globally. And we don’t need to invest a penny for that; we can utilize computer resources that are virtually everywhere.
Software-defined networking is a radical change in the way networking is approached today as it brings the entire software development ecosystem close to the network, allowing operators to integrate all the network resources into the application domain. We moved to IBM Cloud Kubernetes and container deployment because you get an environment where you can run services that are rather simple in a five-nine — 99.999 percent service availability — environment. And it’s a five-nine environment that you get mostly for free, by following Kubernetes or cloud-native principles. With Kubernetes, there’s a common API. It works on private cloud and private deployment, but it also works in public clouds. You are totally agnostic, from developer notebook to private cloud deployments to edge deployments. You deploy in exactly the same way again and again. And this is only possible with Kubernetes.
Promise of 5G
For our industry, there’s a promise of 5G, and that cannot be fulfilled by the carrier alone anymore. There needs to be trust between operators and cloud providers to deliver a distributed infrastructure. Operators trust software vendors like us to create services for them. The whole 5G promise needs to be on more shoulders than it is at the at the moment, so that’s a little bit of a paradigm shift. It’s the first time in the mobile industry that we have had this shift. We need to create another infrastructure for communications services in the field, and that needs to be distributed; the cloud is the foundation for that. You don’t need to mount telecommunications equipment in owned data centers anymore because 90 percent of the spec is available in the cloud. You can book resources wherever you want to go. And this is a huge advantage — global carriers or local carriers can act globally and fulfill local regulations. A company from Germany can deploy in South Korea, as we have done on IBM Cloud. This was not possible in the past, but it’s possible today with cloud resources. In our experience, especially in Europe, IBM plays a role because it is a trusted partner of big customers, and therefore the entry was relatively easy for us.
Read the Travelping case study for more details.
 
The post Driving innovation for connected cars using IBM Cloud appeared first on Cloud computing news.
Quelle: Thoughts on Cloud