Skip to content

[enterprise-3.10] Add static pod / arch changes to 3.10 relnotes #10104

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jun 14, 2018
Merged

[enterprise-3.10] Add static pod / arch changes to 3.10 relnotes #10104

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
135 changes: 100 additions & 35 deletions release_notes/ocp_3_10_release_notes.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -87,11 +87,104 @@ This release adds improvements related to the following components and concepts.
[[ocp-310-notable-technical-changes]]
== Notable Technical Changes

{product-title} 3.9 introduces the following notable technical changes.
{product-title} 3.10 introduces the following notable technical changes.

[discrete]
[[ocp-310-change1]]
=== Change 1
[[ocp-310-major-changes-to-cluster-architecture]]
=== Major Changes to Cluster Architecture

{product-title} 3.10 introduces major architecture changes in how control
plane and node components are deployed, affecting new installations and upgrades
from {product-title} 3.9.

_(New architecture changes diagram, WIP)_

The following sections highlight the most significant changes, with more detail
provided in the Architecture Guide.

[discrete]
[[ocp-310-control-plane-changes]]
==== Control Plane as Static Pods

While previously run as systemd services, the control plane components
(apiserver, controllers, and etcd when co-located with a master) are now run as
static pods by the kubelet on master hosts.

This is now the only supported way they can be run; system containers are no
longer supported, with the exception of the node service RHEL Atomic Host. The
upgrade will change over to the new architecture automatically. Control plane
components continue to read configurations from the *_/etc/origin/master/_* and
*_/etc/etcd/_* directories.

You can see the pods after the control plane starts using `oc get pods -n kube-system`,
and `exec`, `log`, and `inspect` them using normal `oc` CLI commands.

[discrete]
===== Why?

Static pods are managed directly by the kubelet daemon on a specific node,
without the API server having to observe it. With this simplified architecture,
master and node static pods do not have an associated replication controller,
and the kubelet daemon itself watches and restarts them if they crash. Static
pods are always bound to one kubelet daemon and always run on the same node with
it.

[discrete]
[[ocp-310-nodes-bootstrapped]]
==== Nodes Bootstrapped from the Master

Nodes are now bootstrapped from the master by default, which means nodes will
pull their pre-defined configuration and client and server certificates from the
master. The 3.10 upgrade will automatically transform your nodes to use this new
mode.

The node components *openshift-sdn* and *openvswitch* are now run using a
DaemonSet instead of a systemd service.

[discrete]
===== Why?

The goal for bootstrapping is to allow faster node start-up by reducing the
differences between nodes, as well as centralizing more configuration and
letting the cluster converge on the desired state. This enables certificate
rotation and centralized certificate management by default (use `oc get csr` to see
pending certificates).

[discrete]
[[ocp-310-containerized-installation-removed]]
==== Containerized Installation Method Removed

The containerized installation method for OpenShift Container Platform (where
components run as standard container images) has been removed and is no longer
supported starting in 3.10. The 3.10 upgrade migrates RHEL Server hosts to the
RPM-based method and RHEL Atomic Hosts to the system container-based method (for
the node service only), which are the only supported methods for the respective
RHEL variants.

[discrete]
===== Why?

This reduces the number of installation and upgrade paths, and aligns better
with features to be introduced in future releases.

[discrete]
[[ocp-310-configuration-files]]
==== Configuration Files

To upgrade from {product-title} 3.9 to 3.10, you must first create
a configuration file that maps your previous master and node configurations to
the new ConfigMap usage, and supply the mapping when initiating your cluster
upgrade. This ensures that the upgrade does not begin without this critical
information, and that you are not left at the end of the upgrade with hosts
using the previous style deployment.

In addition, the *_/etc/sysconfig/(origin|atomic-openshift)-(api|controllers)_*
files will no longer be used. A new *_/etc/origin/master/master.env_* file can
be used to set environment variables for the static pods. The set of
configuration available as environment variables is limited (proxy and log
levels). Future versions of {product-title} will remove this configuration in
favor of control plane files, so consider the *_master.env_* file a last resort
and deprecated.

[[ocp-310-bug-fixes]]
== Bug Fixes
Expand Down Expand Up @@ -308,39 +401,11 @@ features marked *GA* indicate _General Availability_.
[[ocp-310-known-issues]]
== Known Issues

* {product-title} 3.10 adds the ability for multiple instances of an APB to be
invoked in the same namespace. This new ability requires relying on a globally
unique identifier (GUID) for each instance. While instances deployed by an 3.9
version of an APB lack the GUID, 3.10 APBs require it.
+
--
A 3.10 APB is unable to manage a 3.9 deployed service because it lacks the
newly required GUID. This causes clusters upgraded from 3.9 to 3.10 to result in
an error if an application that was previously deployed on 3.9 is then
deprovisioned from 3.10 APB.

There are two workarounds to this issue currently:

* After the cluster upgrade to 3.10 has completed, delete the namespace of the
application and recreate it. This will use the 3.10 version of the APB and
function as expected.

* Modify the configuration of the OpenShift Ansible broker to remain on the 3.9
version of APBs. This is not recommended, however, as it has the downside of the
broker using 3.10 code while the APBs use the older 3.9 version:

.. Follow the procedure in
xref:../install_config/oab_broker_configuration.adoc#install-config-oab-modifying[Modifying the OpenShift Ansible Broker Configuration] to change the label to `v3.9`.
.. Run the `apb bootstrap` command to bootstrap the broker and relist the catalog.

(link:https://bugzilla.redhat.com/show_bug.cgi?id=1586108[*BZ#1586108*])
--

[[ocp-310-asynchronous-errata-updates]]
== Asynchronous Errata Updates

Security, bug fix, and enhancement updates for {product-title} 3.9 are released
as asynchronous errata through the Red Hat Network. All {product-title} 3.9
Security, bug fix, and enhancement updates for {product-title} 3.10 are released
as asynchronous errata through the Red Hat Network. All {product-title} 3.10
errata is https://access.redhat.com/downloads/content/290/[available on the Red
Hat Customer Portal]. See the
https://access.redhat.com/support/policy/updates/openshift[{product-title}
Expand All @@ -360,8 +425,8 @@ emails to generate.

This section will continue to be updated over time to provide notes on
enhancements and bug fixes for future asynchronous errata releases of
{product-title} 3.9. Versioned asynchronous releases, for example with the form
{product-title} 3.9.z, will be detailed in subsections. In addition, releases in
{product-title} 3.10. Versioned asynchronous releases, for example with the form
{product-title} 3.10.z, will be detailed in subsections. In addition, releases in
which the errata text cannot fit in the space provided by the advisory will be
detailed in subsections that follow.

Expand Down