- About
- Release Notes
- Getting Started
- Architecture
- Installation and Configuration
- Overview
- Installing a Cluster
- Setting up the Registry
- Setting up a Router
- Upgrading a Cluster
- Downgrading
- Master and Node Configuration
- Adding Hosts to an Existing Cluster
- Loading the Default Image Streams and Templates
- Configuring Custom Certificates
- Redeploying Certificates
- Configuring Authentication and User Agent
- Syncing Groups With LDAP
- Configuring LDAP failover
- Configuring the SDN
- Configuring Nuage SDN
- Configuring for AWS
- Configuring for OpenStack
- Configuring for GCE
- Configuring for Azure
- Configuring Persistent Storage
- Overview
- Using NFS
- Using GlusterFS
- Using OpenStack Cinder
- Using Ceph RBD
- Using AWS Elastic Block Store
- Using GCE Persistent Disk
- Using iSCSI
- Using Fibre Channel
- Using Azure Disk
- Using Azure File
- Dynamic Provisioning and Creating Storage Classes
- Volume Security
- Selector-Label Volume Binding
- Enabling Controller-managed Attachment and Detachment
- Persistent Storage Examples
- Overview
- Sharing an NFS PV Across Two Pods
- Complete Example Using Ceph RBD
- Complete Example Using GlusterFS
- Dynamic Provisioning Example Using GlusterFS
- Mounting Volumes To Privileged Pods
- Backing Docker Registry with GlusterFS Storage
- Binding Persistent Volumes by Label
- Using StorageClasses for Dynamic Provisioning
- Using StorageClasses for Existing Legacy Storage
- Working with HTTP Proxies
- Configuring Global Build Defaults and Overrides
- Configuring Pipeline Execution
- Configuring Routing
- Routing from Edge Load Balancers
- Aggregating Container Logs
- Aggregate Logging Sizing Guidelines
- Enabling Cluster Metrics
- Customizing the Web Console
- Revision History
- Administrator Solutions
- Cluster Administration
- Overview
- Managing Nodes
- Managing Users
- Managing Projects
- Managing Pods
- Configuring Service Accounts
- Managing Authorization Policies
- Image Policy
- Scoped Tokens
- Monitoring Images
- Managing Security Context Constraints
- Setting Quotas
- Setting Multi-Project Quotas
- Setting Limit Ranges
- Pruning Objects
- Garbage Collection
- Scheduler
- Allocating Node Resources
- Overcommitting
- Assigning Unique External IPs for Ingress Traffic
- Out of Resource Handling
- Monitoring Routers
- High Availability
- IPtables
- Securing Builds by Strategy
- Restricting Application Capabilities Using Seccomp
- Sysctls
- Encrypting Hosts with IPsec
- Building Dependency Trees
- Backup and Restore
- Troubleshooting Networking
- Diagnostics Tool
- Idling Applications
- Revision History
- CLI Reference
- Developer Guide
- Overview
- Application Life Cycle Management
- Authentication
- Projects
- Migrating Applications
- Application Tutorials
- Builds
- Deployments
- Templates
- Opening a Remote Shell to Containers
- Service Accounts
- Managing Images
- Image Signatures
- Quotas and Limit Ranges
- Getting Traffic into a Cluster
- Routes
- Integrating External Services
- Secrets
- ConfigMaps
- Using Daemonsets
- Pod Autoscaling
- Managing Volumes
- Using Persistent Volumes
- Executing Remote Commands
- Copying Files
- Port Forwarding
- Shared Memory
- Application Health
- Events
- Downward API
- Managing Environment Variables
- Jobs
- Scheduled Jobs
- Create from URL
- Revision History
- Creating Images
- Using Images
- REST API Reference
Overview
The following release notes for OpenShift Container Platform 3.4 summarize all new features, major corrections from the previous version, and any known bugs upon general availability.
Versioning Policy
OpenShift Container Platform provides strict backwards compatibility guarantees for all supported APIs, excluding alpha APIs (which may be changed without notice) and beta APIs (which may occasionally be changed in a non-backwards compatible manner).
The OpenShift Container Platform version must match between master and node hosts, excluding
temporary mismatches during cluster upgrades. For example, in a 3.4 cluster, all
masters must be 3.4 and all nodes must be 3.4. However, OpenShift Container Platform will
continue to support older oc clients against newer servers. For example, a 3.3
oc will work against 3.2, 3.3, and 3.4 servers.
Changes of APIs for non-security related reasons will involve, at minimum, two
minor releases (3.1 to 3.2 to 3.3, for example) to allow older oc to update.
Using new capabilities may require newer oc. A 3.2 server may have additional
capabilities that a 3.1 oc cannot use and a 3.2 oc may have additional
capabilities that are not supported by a 3.1 server.
X.Y ( |
X.Y+N [1] ( |
|
X.Y (Server) |
|
|
X.Y+N [1] (Server) |
|
|
Fully compatible.
oc client may not be able to access server features.
oc client may provide options and features that may not be compatible with the accessed server.