OpenShift Roadmap Enterprise Kubernetes for Developers Clayton Coleman, Architect, OpenShift
What Is OpenShift? Application-centric Platform INFRASTRUCTURE APPLICATIONS Use containers for efficiency Hide details of underlying infrastructure with app specific abstractions Portable across different clouds or metal Package my application and all of its dependencies Deploy to any environment in seconds and enable CI/CD Config driven approach - possible to define application in bulk
Why OpenShift? How is it different from Kubernetes? Provide a secure multi-tenant distribution of Kubernetes Optimized for team software development and deployment Able to create and deploy applications in seconds And run and support all of the stateful parts of an application Easily.
Our Goals What is the mission of OpenShift Origin Make Kubernetes the best place to run all applications Provide well integrated tools to empower developers Ensure that applications can be portable to any environment Make powerful infrastructure available to devs, easily
OpenShift 3.3
3.3 Highlights Released Sept 15 Kubernetes 1.3 & Docker 1.10 CI / CD Pipelines based on Jenkins Pipelines in alpha Application configuration and management improvements Web Console navigation & usability Add to Project from Docker image or template via Web Console A/B deployment routing configuration Significant performance improvements Improvements in image management and updates to Registry 2.4 Better debugging of applications in the web console and CLI Idling / unidling of applications Kerberos CLI support and improved security, authorization, and OAuth tools Improvements in scheduling - affinity, anti-affinity, and more
Native pipelines - Easily launch a pipeline build Jenkins on tap - Created on demand - Responds to requests for builds - Uses plugins for dynamic workers, deep integration
User Experience 1.3 updates: - Navigation menu structure - Pipelines - Metrics - Add to Project capabilities
Pet Sets for Stateful Services Instance 1 Instance 2 Instance 3 Instance 4 Instance 5 Designed for clustered applications where the Pods must obey ordering / identity Need for an extensible interface Made for applications with unique storage to instance pairing requirements Better handling of local storage Incredible amount of classic application clustering being instrumented HA IP addresses/dynamic IP of app instances Leader election Highly Available Pods
Config Maps, Init Containers and Downward API Init Containers - perform pod init in order ConfigMap my.conf=... override.1=... 1 2 Runs first - retries on failure Runs after first Share common config across multiple pods * Great for static configuration 3 3 3 Downward API allows greater flexibility in pod customization Pod API metadata: annotations: parent=db status: podip=172.0.4.6 Started in parallel after all init containers succeed Inject as file in arbitrary location Substitute as env var
A/B Routing OpenShift deployments already support rollover Deployment rollover Service As well as blue / green cutover Change from old to new all at once New components are brought into rotation when they become ready Not Ready Service Blue / Green Pre-existing Ready OpenShift 1.3 supports weighted backends for Routes * Assign percentages to each backend * Turn individual backends on and off Pre-existing New Route 90% 10% 0% $ oc set route-backends a=90 b=10 c=0 Service A Service B Service C $ echo or the awesome web console tools
Image Registry Enhancements integrated stand-alone Manage image content with new integrated registry capabilities Visualization of image metadata and image layer details Standalone registry install option
OpenShift Build Enhancements & Integration Users Have A Choice (we need to expose it better): Build from source Git repo as input, optional WebHooks, etc. Build from application binaries Path to binaries as input (JARs/WARs) Just run my images Customer builds images outside OpenShift
OpenShift Next
Roadmap What are our big ticket near term items? Make Kubernetes more multi-tenant and extensible Continue to evolve Deployments, Ingress, and Stateful Sets Jenkins Pipelines should be able to fully leverage OpenShift Reliability, scale, ease of installation, and overall usability!
Future Plans Over Kubernetes 1.4 and 1.5 releases Application Runtime Dynamic Provisioning for Storage Persistent Volumes Storage tiers for separating types of storage Local persistent volumes Improved node stability and eviction More control at runtime over pod resources Advanced resource planning and management Scheduled Jobs - cron for the cluster Application Development Better support for binary builds Service Linking and Service catalog Improvements to upstream deployments PetSet and DaemonSet upgrades
Future Plans (cont.) Over Kubernetes 1.4 and 1.5 releases Platform Control OpenAPI (Swagger 2.0) Schema Support for etcd3 and much more efficient storage Continued performance tuning and refinement Better extensibility Make it easier to build and implement extensions to Kubernetes Continue to make it easier to integrate with the API Better security controls, better tools Using the Container Networking Interface (CNI) for more flexibility
Enterprise Kubernetes for Developers Get Involved: https://openshift.org Get the Code: https://github.com/openshift/origin Talk to the team: #openshift-dev on freenode Thanks!
1.4 Highlights Alpha 1 released Nov 4, release coming soon Kubernetes 1.4 & Docker 1.12 CI / CD Pipelines based on Jenkins Pipelines enabled by default, secure Web Console navigation & usability Add to Project from Docker image or template via Web Console openshift-sdn is now a CNI plugin
User/Developer Experience - more Make docker builds secure Limit builds to specific nodes Better support for private Git repos Local Maven setup Volumes for build pods Multiple tags on build output Historical logs in web ui Autoscaling based on custom metrics Manage Project membership Log integration and common logging
Join Us @OpenshiftCommons https://commons.openshift.org/gathering Learn more at the upcoming OpenShift Commons Gathering November 7th Seattle