Announcing Speaker Line-Up for Openshift Commons Gathering in London January 29th 2020

OpenShift Commons Gathering in London brings together the OpenShift, Kubernetes, and Operator communities for a day-long OpenShift Commons Gathering on January 29th, 2020 at the IET London: Savoy Place.
Register Now!
The event will feature guest speakers from Worldpay, Public Health England and Asiakastieto. 
Speaker line up announced!

Future Finance Data Innovations with Open Banking and PSD2 – OpenShift Case Study at Asiakastieto by Eero Arvonen (Suomen Asiakastieto)
OpenShift Hive at Worldpay by Bernd Malmqvist (Worldpay) and Matt Simons (Worldpay)
State of Operators: Frameworks, Hubs, SDKs and the Road Ahead by Guil Barros (Red Hat)
OpenShift 4 Release Update and Road Map by Duncan Hardie (Red Hat)  and Jan Kleinert (Red Hat)
OpenShift State of the Union: Unified Hybrid Cloud  by Julio Tapia (Red Hat)
OKD 4 Release Update by Christian Glombek, OKD-WG co-chair (Red Hat)

In the afternoon, closing the day with the ever popular “Ask-Me-Anything” (AMA) live Q&A session with  Red Hat engineers, and upstream project leads.  The day includes an Evening Reception and Networking Event hosted by members of the OpenShift Commons community.
See the full agenda!
Sponsor Opportunities Available for OpenShift Commons Gathering London
Want to connect with the community? Sponsoring the OpenShift Commons Gathering is a great way to expand our joint collaboration and get face-to-face interaction with leaders and members of the Kubernetes & OpenShift ecosystem. Sponsorships are selling out quickly but you can review remaining sponsorship opportunities available here.
The OpenShift Commons Gatherings bring together experts from all over the world to discuss container technologies, best practices for cloud native application developers and the open source software projects. These events are designed for optimal peer-to-peer networking as ample time is given for networking with speakers and all the attendees.
To learn more about OpenShift Commons, please visit and join us soon!
The post Announcing Speaker Line-Up for Openshift Commons Gathering in London January 29th 2020 appeared first on Red Hat OpenShift Blog.
Quelle: OpenShift

Introduction to DevSecOps by John Willis (Red Hat) – OpenShift Commons Briefing

In this briefing, DevSecOps expert, John Willis, Senior Director, Global Transformation Office at Red Hat gives an introduction to DevSecOps and a brief history of the origins of the topics.
He also covers:

Why traditional DevOps has shifted and what this shift means.
How DevSecOps can change the game for your team.
How to get DevSecOps initiatives started within your organization.

About the Speaker:
John Willis is a Senior Director in Red Hat’s Global Transformation Office. Prior to Red Hat, he was the Director of Ecosystem Development for Docker, which he joined after the company he co-founded (SocketPlane, which focused on SDN for containers) was acquired by Docker in March 2015. Previous to founding SocketPlane in Fall 2014, John was the Chief DevOps Evangelist at Dell, which he joined following the Enstratius acquisition in May 2013. He has also held past executive roles at Opscode/Chef and Canonical/Ubuntu. John is the author of 7 IBM Redbooks and is co-author of the “DevOps Handbook” and the upcoming Beyond the Phoenix Project.
Slides: Intro to DevSecOps
Join the DevSecOps SIG Community
Join the conversation and collaborate with the DevSecOps community by joining the DevSecOps Special Interest Group on Google group here:!forum/DevSecOps

This group is for discussion,sharing best practices and help deploying, integrating and implementing DevSecOps.
About OpenShift Commons
OpenShift Commons builds connections and collaboration across OpenShift and OKD communities, upstream projects, and stakeholders. In doing so we’ll enable the success of customers, users, partners, and contributors as we deepen our knowledge and experiences together.
Our goals go beyond code contributions. OpenShift Commons is a place for companies using OpenShift to accelerate its success and adoption. To do this, we’ll act as resources for each other, share best practices and provide a forum for peer-to-peer communication.
To stay abreast of all the latest announcements, briefings and events, please join the OpenShift Commons and join our mailing lists & slack channel.
Join OpenShift Commons today!
The post Introduction to DevSecOps by John Willis (Red Hat) – OpenShift Commons Briefing appeared first on Red Hat OpenShift Blog.
Quelle: OpenShift

Cloud in 2020: The year of edge, automation and industry-specific clouds

It was a banner year for cloud computing in2019. The area that gained the most ground was hybrid multicloud, which emerged as the favored strategy of enterprises looking for a flexible and efficient way to move their workloads to the cloud while reducing costs, boosting productivity and avoiding vendor lock-in. Those advantages are so significant that hybrid cloud is now estimated to be a $1.2 trillion opportunity.
That momentum will accelerate further in 2020 as businesses in all sectors use hybrid multicloud strategies to rapidly roll out applications that accelerate the digital transformation of their businesses while delivering exceptional experiences to their customers. At the same time, enterprises will increasingly turn to advanced encryption and protection solutions to ensure that their clouds remain secure in today’s threat-rich environment, and they’ll embrace emerging technologies like edge to extend the reach of their capabilities. They’ll also begin to adopt automation tools to make it easier to keep their complex cloud ecosystems humming along.
Let’s dive deeper into five trends, which we expect to see in the year ahead as enterprises continue on their cloud journeys.
1. 5G will enable more enterprises to use edge as part of their hybrid cloud strategies
Edge computing, where computations are performed as close to where the data is generated as possible, is in many ways the next chapter in cloud. Retailers will benefit from faster updates on consumer buying trends, factories will be able to perform predictive maintenance on equipment that’s about to fail, cellphone carriers will be able to support mobile gaming and augmented reality.
5G is a critical element as more enterprises look to incorporate edge as part of their hybrid cloud strategies. Hybrid cloud will continue to serve as an aggregation point for the most relevant data and back-end functions, while the edge can support analytics and other core functions in real-time where the data is created and actions are taken.
“Edge computing is a transformative technology,” says Ryan Anderson, IBM platform strategist, CTO group for edge development. “Edge is an enabling technology to deliver things that do work to the places that work needs to get done.”
5G is edge’s key enabling technology because it delivers the higher speeds and broader bandwidths required to cut data latency to the bone. As 5G deployments begin to hit the cellular airwaves, hybrid cloud ecosystems will increasingly take advantage of opportunities to perform computations at the edge. The resulting innovations are projected by the GSMA’s Mobile Economy report to contribute as much as $2.2 trillion to the global economy over the next 15 years.
2. Automation will dominate the next phase of hybrid multicloud
Companies are adopting hybrid multicloud strategies at a rapid clip, taking advantage of the flexibility to move mission-critical business applications to the environment of their choosing — public cloud, on-premises or private clouds. Indeed, hybrid cloud is a $1.2 trillion market opportunity and nearly 80 percent of IT decision makers see it in their future. However, the very advantages of hybrid environments, including resiliency, scalability and support for a broad variety of applications, APIs and data types, means they are by nature complicated.
“One of the challenges that’s going to become really important is managing the hybrid multicloud landscape,” says Bala Rajaraman, IBM Fellow and VP IBM Hybrid Cloud. “In 2020, even more enterprises will find themselves using multiple clouds, and the make-or-break for capitalizing on these investments will be how they effectively manage all this data spread across environments.”
The upshot is that automated tools — including early offerings that incorporate artificial intelligence — will emerge in 2020 to help manage this complexity. “AI is transitioning into a function that helps manage operations complexity and security,” says Hillery Hunter, VP & CTO of IBM Public Cloud.
Along with increasingly automated tools, dashboards that provide a big-picture overview of cloud operations will become an important tool for administrators. This will enable enterprises to tune their environments, putting the right workloads in the right place, controlling costs and managing security keys and encryption effectively.
3. Security “command centers” will proliferate as part of hybrid cloud strategies
Some 60 percent of IT decision makers rated security as the most important attribute in selecting a cloud provider. In 2020, tools will emerge that can uncover security insights and respond to incidents faster through dashboards that help centralize operations.
“In the hybrid multicloud world, you need a command center,” says Hunter. “Traditionally, that’s been called a security operations center. That whole space is evolving significantly. We’re seeing tremendous resonance on the notion that a single dashboard in hybrid multicloud is going to be important.”
The emergence of DevSecOps, where security is integrated into the development process itself, is another indication that a more connected security ecosystem is in the cards for 2020.
“Security posture and visibility across all environments is one of the next fronts,” says Hunter.
4. More adoption of industry-optimized clouds, beyond banking
As organizations turn to the cloud, they’re looking for solutions that serve the needs of their specific industry. For highly regulated industries in particular, this means features that offload the burdens of compliance. According to a recent study by Thomson Reuters, financial service organizations, for example, deal with an average of 220 regulatory updates per day — and 71 percent of firms expected that number to increase in the next year.
The financial-services-ready public cloud launched in 2019. That Bank of America will use this industry-specific cloud to host key applications and workloads to support its 66 million banking customers provides both an important proof point and a useful template that other industries will follow.
“We’re going to see more and more industry-specific characteristics,” says Rajaraman. “Ecosystems will have to target particular markets, because it’s very hard to be generic. So, there will be more of a focus on delivering industry-specific value and addressing industry-specific requirements.”
Global research from IBM shows that only 40 percent of organizations today have the skills and strategy to manage a multicloud environment. Here, industry specific clouds help organizations by shielding them from the complexities of their cloud infrastructure and architecture. Perhaps that’s why, according to a recent survey, 61 percent of respondents said that one of the biggest benefits of adopting industry cloud services was ease of management and administration.
5. Open source tools will proliferate to make Kubernetes more consumable
Open source technology is having a profound impact on cloud. In 2019, enterprises turned to open source software to modernize their infrastructure and accelerate their adoption of hybrid multicloud. In 2020, developers will focus on tools that can support rapid deployment of applications, which their businesses need to stay at the cutting edge of digital transformation.
This means widespread uptake of the continuous delivery paradigm, where organizations embrace the DevOps philosophy of rapid builds, tests and deployments. The continuous delivery model is growing in tandem with the increased development of cloud-native applications built from the start to be deployed through containers and Kubernetes.
“You’re going to see an amplification of people moving to Kubernetes and OpenShift in 2020 and start adopting technologies like Red Hat Operators to become an integral part of the Kubernetes ecosystem,” says Rajaraman.
In sum, as we look ahead, enterprises will have a growing palette of options at their disposal to facilitate workload management, speed application deployments, ensure maximum security, exploit additive technologies such as edge, and more. Indeed, the brave new cloud world of the decade that’s about to begin will deliver value, resiliency and responsiveness that could only be dreamt of just a few short years ago.
The post Cloud in 2020: The year of edge, automation and industry-specific clouds appeared first on Cloud computing news.
Quelle: Thoughts on Cloud

OpenShift 4.x Installation – A Quick Overview

In this video we will look at the options to install an OpenShift 4.x cluster and will see a fully automated quick installation with minor customizations on a cloud provider.
The post OpenShift 4.x Installation – A Quick Overview appeared first on Red Hat OpenShift Blog.
Quelle: OpenShift

Multicloud management: Why visibility, security and automation matter to CIOs

As a C-level or line of business executive, there’s a lot that can keep you up at night. While it’s critical that you invest in new technology to keep up with your competition, you don’t want to risk a gap in security or lose out on your current investments — whether it’s your technology, your people or your budget.
And if you do decide to spend the money and take the time required to modernize, you’re probably wondering if doing so will jeopardize your enterprise’s ability to remain secure and compliant, provide the ROI that you expect and most importantly maintain an optimized customer experience. A negative outcome to any of these areas could tarnish brand reputation and even cost your enterprise financially.
Multicloud management: Three key considerations
Now let’s think about this from the perspective of managing your hybrid, multicloud environment, and address the issues that your IT Operations and Site Reliability Engineer (SRE) teams may face daily. Ask yourself these three questions:

Governance and security. Can your teams easily enforce your enterprise’s policies, and know that the risk of a security breach is minimal?
Visibility. Do your teams have clear line of site across your environments and the ability to easily diagnose and triage issues? Are their actions powered by key business indicators and predicative monitoring?
Automated operations. Are your delivery, configuration, and management processes slow and manual, or are they efficient and automated, thus driving cost savings and improved productivity?

If you answered “no” to any of these questions, don’t worry, you’re not alone. According to a 2018 IBM Institute for Business Value study, more than 60 percent of customers responding state that they don’t have the tools and procedures to manage and operate in a complex multicloud environment.
Multicloud management: Finding a solution
IBM Cloud Pak for Multicloud Management, is an integrated suite of capabilities that delivers lifecycle management for cloud-native and traditional applications, as well as infrastructure lifecycle management for Kubernetes and Virtual Machines (VMs), underpinned with a consistent event management, automation and enterprise policy compliance framework.
Your enterprise can benefit by managing VMs and containers from a single control point which can increase operational efficiency that’s driven by intelligent data analysis and Golden Signal monitoring.
A 2019 Ovum report sponsored by IBM found that IBM Cloud Pak for Multicloud Management can reduce development time by up to 84 percent and operational expenses by up to 75 percent.
The addition of Red Hat capabilities can support your infrastructure, security and application management.
IBM Cloud Pak for Multicloud Management v1.2 includes additions to infrastructure, security and application management. But what’s more exciting is the addition of Red Hat CloudForm functionalities and the integration with Ansible Automation Platform. A new UX can help your operations team easily communicate to Ansible playbooks and perform day-two operations, thus helping to control inventory, discovery and management for VM-based applications.

Runbooks that event management executes to remediate problems can now be written in Ansible.
Operators can automate the configuration of networks, storage attachments in clouds and compute resources as part of application development using preexisting Ansible playbooks.
IT automation needed for operations or setup/deployment/configuration, scripting can be performed using Ansible.

Wherever you are on your cloud management journey, IBM can meet you there.
Hopefully you can sleep better at night knowing that your hybrid, multicloud environment can be modernized, secured and managed while you continue to use your existing investments. You can consistently automate deployment, manage, protect and govern applications wherever your workloads run, while driving operational efficiency to gain a competitive advantage and improving service levels.
Learn more.

Watch: IBM Cloud Pak for Multicloud Management in one minute
Watch: IBM Cloud Pak for Multicloud Management – demo video
Visit: IBM Cloud Pak for Multicloud Management website

The post Multicloud management: Why visibility, security and automation matter to CIOs appeared first on Cloud computing news.
Quelle: Thoughts on Cloud

OpenShift Scale-CI: Part 3 – OCP 4.1 and 4.2 Scale Run Highlights

In part one of the series, we discussed how the Red Hat OpenShift Scale-CI evolved. In part two of the series, we looked at the deep dive and various components of Scale-CI. In this post, we will look at the highlights of how we used OpenShift Scale-CI to test and push the limits of OpenShift 4.1 which is the first OpenShift 4.x release and OpenShift 4.2 at scale.
We typically use hardware resources from the scale lab, a datacenter built and managed by Red Hat’s Performance and Scale team with the goal to provide compute resources on demand to various teams across Red Hat to solve problems related to Performance and Scalability. We install OpenStack on the bare metal machines to manage the resources and then install OpenShift on the virtual machines. In OpenShift 3.x, the installer doesn’t take care of provisioning which means that we need to build wrapper scripts to create virtual machines for installing and scaling up OpenShift whereas the OpenShift 4.x IPI (Installer Provisioned Infrastructure) based installer takes care of provisioning and scaling up the cluster to higher node counts literally takes minutes versus hours. Redhat Enterprise Linux CoreOS is the default base operating system for OpenShift 4.x, It is immutable which means that configurations and packages can’t be changed or installed on the host, everything needs to run as a container. The cluster has full control over the nodes, this will avoid configuration drifts leading to easier upgrades and achieves repeatability and auditability. The following diagram shows the fully automated day 1 and day 2 operations:

A single blog post won’t be sufficient to elaborate on the amazing features and enhancements including the operators, you can refer to the 4.1 release notes and 4.2 release notes to know about all the features.
Let’s jump straight into the OpenShift 4.1 and 4.2 scale test run highlights. We picked AWS and GCP as the cloud platforms to host OpenShift 4.1 and 4.2 clusters respectively. AWS is the only supported provider ( Installer Provisioned Infrastructure ) for the OpenShift 4.1 release while GCP, Azure and Red Hat OpenStack Platform are also supported in OpenShift 4.2. Here is the cluster configuration:

The 4.1 and 4.2 clusters consisted of 3 Masters/Etcd with io1 and SSD storage in the case of AWS and GCP respectively, etcd is i/o intensive especially when the cluster consists of large number of nodes and objects. We create infrastructure nodes using custom machinesets as part of day 2 operation to host prometheus, router, registry and logging instead of using bigger worker nodes and setting the limits on the deployments for the infrastructure components  to be scheduled on nodes with the available resources.
We ran a bunch of scale tests including:

Kubelet density focused test which spawns maximum pods across the worker nodes which is 250 ( current cluster limits for OpenShift 4.1 and 4.2 ).
Control plane density focused tests which creates a bunch of projects with secrets, configmaps, routes, builds, deployments e.t.c across the cluster to stress the apiserver, etcd and controller on masters/etcd nodes.
HTTP/Router scale test, a data-plane workload generator that runs http requests through through HAProxy into deployed pods.
Cluster Limits, we ran a bunch of tests to validate and push the limits for the OpenShift 4.1 and 4.2 releases. The findings have been documented as part of the Scalability and Performance guide to help users/customers plan their environment according to the object limits. The following table shows the cluster limits for various OpenShift releases:

Networking scale tests which runs uperf benchmarks testing node to node, pod to pod, and svc to svc throughput and latency for TCP and UDP protocols.

We also ran scale tests focusing on Monitoring ( Prometheus ), Logging ( Fluentd and Elasticsearch ), Storage and Registry. The scale tests are all hosted in workloads and svt repositories and are triggered using the pipeline. Here are some of the interesting findings, tunings and recommendations from the runs:

Etcd is a critical component of OpenShift, It stores and replicates the cluster state.

For large and dense clusters, etcd can suffer from poor performance if the keyspace grows excessively large and exceeds the space quota. Periodic maintenance of etcd including defragmentation needs to be done to free up space in the data store. It is highly recommended that we monitor Prometheus for etcd metrics and defragment it when needed before etcd raises a cluster-wide alarm that puts the cluster into a maintenance mode, which only accepts key reads and deletes. Some of the key metrics to monitor are etcd_server_quota_backend_bytes which is the current quota limit, etcd_mvcc_db_total_size_in_use_in_bytes which indicates the actual database usage after a history compaction, and etcd_debugging_mvcc_db_total_size_in_bytes which shows the database size including free space waiting for defragmentation. The default Etcd space quota is 7GB, it should be good enough to support large and dense clusters. Etcd maintenance is a day 2 operation as the defragmentation is not done automatically, it is essential to monitor the metrics mentioned and act accordingly.

Some users have requirements especially when running OpenShift on bare metal nodes might not have the luxury to use thousands of nodes in case they want to run thousands of pods. This motivated us to work on pushing the pods per node limit beyond the current supported limit of 250 pods per node – the work is still in progress.
Scaling up the cluster to higher node counts is as simple as changing the replica count of the worker machinesets. The worker nodes are distributed across various zones of a region in the public cloud ( AWS and GCP in our case ), it’s recommended to spread them across the availability zones evenly during the scaleup as well for higher availability.
We ran baseline workload to collect data on a base cluster with no applications running except the system components. As we keep adding enhancements to make OpenShift self healing/managed by operators, support over the air upgrades to make our life easy and also have a better user experience, the number of containers/components which run by default on the cluster increased when compared to OpenShift 3.x. The document has details about the recommended master node sizes for various node scale.
ROUTER_THREADS is 4 by default in OpenShift 4.x, the router performance optimizations have been documented as part of the OpenShift Scalability and Performance Guide.
The new fluentd version 1.2.x used in OpenShift 4.1 and 4.2 provides over twice the single node message throughput as the version used in OpenShift 3.x.
The Elasticsearch version used in OpenShift 4.1 and 4.2 is unchanged from OpenShift 3.11 and message indexing throughput is comparable to that release.
Source-to-image (S2I) build times in OpenShift 4.1 were longer than previous releases for several reasons related to how s2i builds are run and pushed to the internal registry.   In OpenShift 4.2, the times were improved by 2x – 3x.
There might be a need to tweak the kubelet config for example the qps/burst rates or the pods per node, it takes hours for the change to take effect on a cluster with large number of nodes as the change triggers a reboot of the nodes to apply the configuration and the number of nodes which can be unavailable at a given time by default is 1, it can be tweaked to speed up the process as documented in the Scalability and Performance Guide.

NOTE: When setting the value, consider the number of worker nodes that can be  unavailable without affecting the applications running on the cluster.

We ran tests focusing on Cluster Monitoring Operator to come up with the Prometheus Database storage requirements based on number of nodes/pods in the cluster, the recommendations have been documented as part of the OpenShift Scalability and Performance Guide.
The rate at which the kubelet talks to the API server depends on queries per second (QPS) and burst values. The default values, 5 for kubeAPIQPS and 10 for kubeAPIBurst, are good enough if there are limited pods running on each node. Updating the kubelet QPS and burst rates is recommended when there are a large number of objects provided there are enough CPU and memory resources on the node, the information on how to tweak the values is discussed in the guide.
Scaling pods with attached PVC was very reliable and consistent with only limitation being the imposition by the public cloud providers on the number of block devices per cloud instance.
The upgrades got much easier and reliable. The machine-config operator will start complaining during the upgrades even if a single file/config is changed on the host.

Look out for part 4: Tooling/Automation Enhancements and Highlights of OpenShift 4.3 Scale Test Run. As always, feel free to reach us on sig-scalability kubernetes slack or on github. Any feedback and contributions are most welcome.
The post OpenShift Scale-CI: Part 3 – OCP 4.1 and 4.2 Scale Run Highlights appeared first on Red Hat OpenShift Blog.
Quelle: OpenShift

Kubernetes 1.17: Volume Snapshots Beta and Scheduler changes for stability and extensibility

It’s almost become boring to say that Kubernetes has become boring. This massive open source project has now been in development for so long that the major changes from revision to revision tend to focus on stability, reliability and performance: the sorts of changes that make life easier every day, but do not look so exciting when listed out in a change log.
In truth, nothing in Kubernetes 1.17 will drastically change how you use containers, but they will result in more powerful and dependable architectures, capable of scaling to meet enterprise needs without buckling under pressure. Indeed, Kubernetes is now not only a stable platform for constructing cloud-native infrastructure, it is a stable foundation for the entire ecosystem of services and projects which rely upon it: from Prometheus to Istio to Fluentd to data services layers and Operators.
That’s not to say there aren’t major enhancements in-bound in this release of the platform. One of those new additions, in fact, can directly affect data services – volume snapshots. That new feature is currently in beta with this release, but has been in development for a considerable amount of time.
Volume Snapshots for better backup, data replication and migration
After two years and two alpha implementations, volume snapshots are beta in this release. Volume snapshots allow users to take a point in time snapshot of their data stored on a PersistentVolume and restore it later as a new volume. Snapshots can be used in a wide variety of use cases, from backup to data replication or migration. 
Kubernetes can use the snapshot feature of any storage backend that implements Container Storage Interface (CSI) 1.0, which has more than 50 drivers already. It is not tied to a couple of hard coded storage providers as in the first alpha implementation. 
The snapshot functionality is in a new external snapshot-controller and csi-snapshotter sidecar. Moving these pieces outside of the kube-controller-manager and kubelet allowed for faster development, better separation of concerns, and proof of the extensibility of the Kubernetes platform.

snapshot-controller, deployed during Kubernetes installation, manages the whole lifecycle of volume snapshots, including taking snapshots, binding of pre-existing snapshots, and restoring or deleting snapshots.
csi-snapshotter sidecar, which runs in the same pod as a CSI driver and is deployed by a CSI driver vendor, serves as a bridge between the snapshot controller and the CSI driver and issues CSI requests to the driver, so CSI drivers do not need to worry about Kubernetes internals.

Volume snapshots help users to consume abstract storage resources for more efficient backup, data replication, migration and more, but there is still work to do. In Kubernetes 1.17, functionality is limited to taking and restoring snapshots of a single volume, but we already have plans to add new features in future Kubernetes releases to allow application-consistent snapshots using execution hooks or taking snapshots of whole StatefulSets.
Scheduling changes
Over the past several releases the scheduling special interest group (sig-scheduling) put together a proposal to improve the extensibility of the default Kubernetes scheduler. The current extensions mechanism is very limited, as it only allows two operations to be specified, namely Filtering and Prioritizing. Additionally, it requires invoking external HTTP requests, which might significantly extend the scheduling time, and lower the overall throughput of the scheduler. 
The new mechanism will allow plugins to be decoupled from core Kubernetes code, while also allowing easier exchange of information between plugins and the scheduler (such as access to the scheduler cache).

The main extension points depicted in the picture above, are as follows:

Sorting – responsible for sorting the pods in the scheduling queue.
Pre-filtering – used for pre-processing the information about pods being currently processed.
Filtering – the process responsible for matching a pod with a particular set of nodes the pod can run on.
Post-filtering – used mainly for information, such as to update the plugin internal state. Alternatively, it can be used as a pre-scoring step.
Scoring – responsible for ranking nodes, scoring has 2 phases:

Scoring – the actual scoring algorithm
Normalize Scoring – to update the score from the previous phase to fit within [MinNodeScore, MaxNodeScore] range. 

Reserve – an informational point, which plugins can use to update its internal state after scoring completes.
Permit – responsible for approving, denying or delaying a pod.
Pre-binding – performs any work required before binding a pod.
Binding – assigns a pod to an actual node.
Post-binding – another informational point, which plugins can use to update its internal state after scoring completes.

More information about the new scheduling framework is available in the KEP. 
It’s important to note that the new mechanism is meant not only for the extenders. To improve the maintainability of the main scheduler components over the course of the next few releases sig-scheduling will be rewriting all the pre-existing scheduler logic to follow the new scheduler framework. 
Volume snapshots and a new scheduler mechanism are two of many pieces that increase the stability and extensibility of Kubernetes.  
Kubernetes 1.17 is expected to be available for download on GitHub this week. This release of Kubernetes is planned to be integrated into a future release of Red Hat OpenShift.
The post Kubernetes 1.17: Volume Snapshots Beta and Scheduler changes for stability and extensibility appeared first on Red Hat OpenShift Blog.
Quelle: OpenShift

5 steps to prime your business for AI

Artificial intelligence (AI), when integrated correctly, enables organizations to learn and then act on information—powering businesses to make predictions, automate processes and optimize logistics. Although AI has the potential to add almost $16T to the global economy by 2030, 81 percent of business leaders do not understand the data and infrastructure required for AI. Businesses need a prescriptive, strategic approach to successfully modernize their information architectures (IA) with AI.
Successful AI models rely on collection and organization of data—a unified and open information architecture is necessary to prime data and ready businesses for an AI and multicloud world. The AI ladder gives organizations a set of guiding principles for the four areas of AI: how to collect, organize and analyze data, and ultimately, how to infuse AI into business practices.
The AI ladder: A prescriptive approach
1. Modernize
“Modernize,” in the AI context, means building an information architecture for AI that provides choice and flexibility across the organization. In order to meet today’s demands and stay competitive tomorrow, organizations need an efficient, agile data architecture.
2. Collect
AI is only as good as the data. Once an organization has modernized its architecture, it’s imperative for them to establish a strong foundation of data, making it simple and accessible, regardless where that data resides.
3. Organize
Confidence in your AI relies on trustworthy, complete and consistent data. Data must be cleansed, organized, catalogued and governed to ensure that only authorized individuals are able to access it.
4. Analyze
Once data is collected and organized in a trusted, unified view, an organization can now build and scale AI models across the business. This allows companies to glean insights from all of their data, no matter where it resides, and engage with AI to transform their business — resulting in a clear competitive advantage.
5. Infuse
Many businesses create highly useful AI models, but then encounter challenges in operationalizing them to attain broader business value. Organizations can help advance their business agenda by putting AI to work in multiple departments and within various processes — from payroll, to customer care, to marketing — drawing on predictions, automation and optimization.
Embracing AI leads to competitive advantage
In today’s hybrid, multicloud world, organizations that modernize their information architecture to embrace artificial intelligence can solve core business problems and create competitive advantage. With the proper tools, business practices and strategy, your organization can unlock the full potential of your data to embrace the power of AI. To learn more about the unique approach and solutions that IBM brings to data modernization and integrating AI, read the smart paper “Modernize Data and AI: Ready your data for AI and multicloud”.
The post 5 steps to prime your business for AI appeared first on Cloud computing news.
Quelle: Thoughts on Cloud

Configuration Drift Prevention in OpenShift: Resource Locker Operator

There are times in which we must be absolutely sure that a set of Red Hat OpenShift configurations “stay in place” lest an application, or potentially the entire cluster, becomes unstable.
The standard mechanism for preventing configuration drift in OpenShift is Role Based Access Control (RBAC); if only subjects with legitimate access can change the configuration, one should be certain that the configuration does not differ from the expectate state. RBAC works fine with this purpose, but there are some limitations:

Complex and fine grained RBAC configurations are difficult to create, especially now that with operators and Custom Resource Definitions (CRD’s), the API surface is ever increasing. Few organizations have the discipline to create a comprehensive RBAC strategy for an OpenShift deployment.
RBAC cannot prevent human error.

In this post, a different and complementary-to-RBAC approach to configuration drift prevention will be presented.
Resource Locker Operator
The purpose of the Resource Locker Operator is to prevent configuration drift on a set of resources. It achieves that goal not by preventing access to those resources, but by watching them and restoring any undesired change. 
While the operator does not replace RBAC, it can be considered complementary to provide a more holistic solution.
With the Resource Locker Operator, one can lock-in two types of configurations:

Resources: any kind of resource can be defined instructing the operator to create that resource and prevent configuration drift on it.
Patches: patches on pre-existing resources can be defined. The Resource Locker Operator will enforce the patch, allowing the rest of the resource to change.

The Resource Locker Operator introduces the ResourceLocker CRD which allows a user to express the desire to lock a configuration. A representation is found below:
kind: ResourceLocker
name: test-simple-resource
– object:
apiVersion: v1
kind: ResourceQuota
name: small-size
namespace: resource-locker-test
requests.cpu: “4”
requests.memory: “2Gi”
name: default

This ResourceLocker configuration defines a ResourceQuota object.
Let’s look in more detail at the different types of configurations that can be applied.
Locking Resource Configurations
The example shown in the previous section illustrated how to define resources within a ResourceLocker object  The resource can be of any type available in the cluster. Given that the resources field is an array, multiple resources can be defined in a singleResourceLocker CR.
Kubernetes resources have fields that legitimately need to change. By default, the metadata and the status fields of all resources are subject to change by the controllers that monitor that specific resource. Instead, the spec portion of the resource is normally used to specify a desired state, which is what we want to lock down. However, there are instances where portions of the spec field have legitimate reason to change themselves. For example, the spec.replicas field in some resource types is considered acceptable to be modified.
The Resource Locker Operator provides a generic mechanism to specify which fields to exclude from consideration. These fields will be free to change, while changes on the other fields will be considered configuration drift and will be reset by the operator. Fields to be excluded from the watch can be specified in the excludedPaths field of the CR. In addition, metadata, status and spec.replicas are always added by default as excluded fields. This default configuration is designed to work without issue in most situations. Given these defaults, the previous example becomes:
– excludedPaths:
– .metadata
– .status
– .spec.replicas
apiVersion: v1
kind: ResourceQuota
name: small-size
namespace: resource-locker-test
requests.cpu: ‘4’
requests.memory: 2Gi

Locking Patch Configurations
Patches are useful when we need to modify an object that we don’t own. For example, node objects are in general owned by the cluster installer or the cluster api controller. It is not uncommon for a cluster administrator to add labels to nodes.
This type of situation is common in sophisticated distributions of Kubernetes, such as OpenShift, in which the install operator (Cluster Version Operator in OpenShift’s case) pre-populates several resources and the administrator can choose to modify those resources to configure the cluster if a specific need arises (day two configuration). In this situation, the administrator does not actually own those resources as those resources are owned by the cluster.
When the cluster upgrades or a specific operator upgrades, they need to be able to change those resources. When the upgrade is completed, the administrator might have to reapply the day two configurations.
By being able to lock in a patch, we avoid having to reapply the day two configurations. As soon as the operator that owns the resource is finished applying the upgrades, the Resource Locker Operator will reapply the configured patch.
A patch can be represented by the following example:
– targetObjectRef:
apiVersion: v1
kind: ServiceAccount
name: test
namespace: resource-locker-test
patchTemplate: |
hello: bye

Here, we are patching the target object, which, in this case, is a service account with a constant annotation. 
We can also patch resources based on values present in other resources:
– targetObjectRef:
apiVersion: v1
kind: ServiceAccount
name: test
namespace: resource-locker-test
patchTemplate: |
{{ (index . 0) }}: {{ (index . 1) }}
patchType: application/strategic-merge-patch+json
– apiVersion: v1
kind: Namespace
name: resource-locker-test
– apiVersion: v1
kind: ServiceAccount
name: default
namespace: resource-locker-test

In the example above, we use the sourceObjectRefs field to specify a list of references to other resources that will become the parameters of our patchTemplate. The patch template field is then processed as a go template receiving as input the array of parameters. The result of the processed template is treated as a patch which is then applied to the target object. 
Additional options are available for patches and can be found in the Resource Locker Operator GitHub repository.
Multitenancy and Security
The Resource Locker Operator runs with very limited privileges (it can only manipulate ResourceLocker resources). However, it still needs to be able to enforce resources and patches on any object type. How is that attained?
When creating a ResourceLocker, the user must also pass a reference to a  service account located in the same namespace as the ResourceLocker CR. This service account will be used to manage the configurations as defined by the given ResourceLocker CR. With this approach, security escalations can be prevented since a user can only enforce actions on resource types for which they were previously granted permissions.  This functionality also provides the ability to run a single Resource Locker Operator instance to control an entire cluster (as opposed to one per namespace).
It’s possible to install the Resource Locker Operator from the OperatorHub or via a Helm chart.
Details on both installation approaches can be found on the Resource Locker Operator GitHub repository.
The Resource Locker Operator provides mechanisms to prevent configuration drift which are complementary to RBAC. It partly overlaps in functionality with a GitOps operator (such as ArgoCD, for example). In fact, a GitOps operator is designed to detect and correct drifts. However, based on my observations, GitOps operators are good at enforcing the resources they own, but they do not provide the capabilities to manage patches.
As with any Open Source project, end user feedback is welcome in order to enhance the overall functionality of the Resource Locker Operator.
The post Configuration Drift Prevention in OpenShift: Resource Locker Operator appeared first on Red Hat OpenShift Blog.
Quelle: OpenShift

SteelHouse cuts application deployment time in half with IBM Cloud Kubernetes Service

People who are shopping, researching, or doing anything at all online don’t want to be held up by a website that takes a long time to load. And, ads are one of the most common reasons for poor website performance.
SteelHouse uses the IBM Cloud to ensure a good user experience, which for the advertising software company translates to an ad being served in approximately 100 milliseconds or less.
With the cloud, we’re able to deploy all over the world and we don’t have to worry about the orchestration or the time that it takes to serve an ad.
A fully managed Kubernetes service
We run a lean organization. For us to continue to compete and deliver great products, which in our case are optimized ad campaigns based on users’ browsing histories, we needed to offload as much as we could to other providers.
We had worked with bare metal machines and VSIs (virtualized server instances), and we were very interested in moving into an ecosystem where we didn’t have to do a lot of managing.
When we found out about the IBM Cloud Kubernetes Service, we chose it as our compute engine because we could standardize how we deployed and how we scaled. By running everything inside Kubernetes, it allows us to have a simple, streamlined environment with a fully managed container service for Docker (OCI) containers. This allows us to be able to deploy containerized apps onto a pool of compute hosts.
We didn’t have to do a Kubernetes installation; we just had to learn how to use and operate Kubernetes. This was simple, in part because the Kubernetes service team at IBM provided great support in getting us up to speed and helping us feel confident that we could move forward in a cloud environment running Kubernetes.
Complementary cloud technologies
Moving to a microservices architecture without Kubernetes would’ve been a nightmare. We have almost 40 microservices under our belt and Kubernetes helps us orchestrate and manage those services. Without that, the amount of manpower required to maintain and service that infrastructure would be magnitudes higher than we can currently accommodate with our staff.
We use IBM Event Streams for IBM Cloud to decouple the back-end services that do the heavy lifting from the front-end services that provide customer interaction. That way, the customer interaction isn’t degraded when we’re doing heavy processing in the back end. IBM Event Streams allows for playback of data that teams may not have been able to process or may need to be reprocessed. If needed, reloading data into the database is just a click of the button.
Additionally, because SteelHouse is part of the Cloud Native Computing Foundation user community, we like to ensure that we use as many products that are part of the foundation as possible, including Istio.
Istio is a service mesh that runs inside Kubernetes routing traffic in between services and blocking unwanted traffic from coming into the network. We chose Istio as our service mesh for the security that it provides and the ability to do retry logic on HTTP requests. Many of our services make HTTP requests to other downstream systems, but those HTTP requests can sometimes fail. Istio provides retry logic without us having to modify our code, which means we don’t have to test and configure applications – it’s just configurable at the service level.
Synergy among the team
By working with IBM Cloud Kubernetes Service, we can offload all the operational work and support and stay focused on the actual products that we’re building.
With the Kubernetes service we can spin up a new data center in 24 hours. It used to take us a month. The service is also helping us reduce ramp-up time for new hires, because it doesn’t take them two months, or six months, or a year to get up to speed and actually deploy something. It now takes them literally a week.
One of the big things that happened when we switched to Kubernetes was that developers began to take control of how applications were configured and how pipelines were built out. This took workloads off of the operations team’s plate and created a new team synergy. Now instead of having to rely on a separate team to do configuration management, our developers can build their own Docker files and deploy content to the cloud instead of running it locally on their machines. Generally, running on Kubernetes has made it possible to deploy things in half the time it used to take.
Overall, we have the ability to move faster, develop and deploy quicker, and have better insight into our applications. We can do all of this with a better service-level agreement (SLA), because we are able to use cloud-managed services that make our team seem bigger than it is.
Watch the video and read the case study to learn more about the SteelHouse journey.
The post SteelHouse cuts application deployment time in half with IBM Cloud Kubernetes Service appeared first on Cloud computing news.
Quelle: Thoughts on Cloud