Release v1.6.11
Versions
- rancher/server:v1.6.11
- rancher/agent:v1.2.7
- rancher/lb-service-haproxy:v0.7.15
- rancher-v0.6.5
- rancher-compose-v0.12.5
Supported Docker Versions
- Docker 1.12.3-1.12.6
- Docker 1.13.1
- Docker 17.03-ce/ee
- Docker 17.06-ce/ee
- Docker 17.09-ce/ee
Note: Kubernetes 1.8 supports Docker 1.12.6, 1.13.1 and 17.03.2. Kubernetes 1.7 supports up to Docker 1.12.6
Rancher Server Tags
Rancher server has 2 different tags. For each major release tag, we will provide documentation for the specific version.
rancher/server:latest
tag will be our latest development builds. These builds will have been validated through our CI automation framework. These releases are not meant for deployment in production.rancher/server:stable
tag will be our latest stable release builds. This tag is the version that we recommend for production.
Please do not the releases with a rc{n}
suffix. These rc
builds are meant for the Rancher team to test out builds.
Beta - v1.6.11 - rancher/server:latest
Stable - v1.6.10 - rancher/server:stable
Important - Upgrade
-
Users on a version prior to Rancher v1.5.0: We will automatically upgrade the
network-services
infrastructure stack as without this upgrade, your release will not work. -
Users on a version prior to Rancher v1.6.0: If you make any changes to the default Rancher library setting for your catalogs and then roll back, you will need to reset the branch used for the default Rancher library under Admin → Settings → Catalog. The current default branch is
v1.6-release
, but the old default branch ismaster
. -
Rollback Versions: We support rolling back to Rancher v1.6.10 from Rancher v1.6.11.
- Steps to Rollback:
- In the upgraded version the Admin → Advanced Settings → API values, update the
upgrade.manager
value toall
. - “Upgrade” Rancher server but pointing to the older version of Rancher (v1.6.10). This should include backing up your database and launching Rancher to point to your current database.
- Once Rancher starts up again, all infrastructure stacks will automatically rollback to the applicable version in v1.6.10.
- After your setup is back to its original state, update the
upgrade.manager
value back to the original value that you had (eithermandatory
ornone
).
- In the upgraded version the Admin → Advanced Settings → API values, update the
- Steps to Rollback:
Note on Rollback: If you are rolling back and have authentication enabled using Active Directory, any new users/groups added to site access on the Access Control page after the upgrade will not be retained upon rolling back. Any users added before the upgrade will continue to remain. [#9850]
Important - Please read if you currently have authentication enabled using Active Directory with TLS enabled prior to upgrading to v1.6.10.
Starting with v1.6.8, Rancher has updated the Active Directory auth plugin and moved it into the new authentication framework. We have also further secured the AD+TLS option by ensuring that the hostname/IP of the AD server matches with the hostname/IP of the TLS certificate. Please see [#9459] for details.
Due to this new check, you should be aware that if the hostname/IP does not match your TLS certificate, you will be locked out of your Rancher server if you do not correct this prior to upgrading. To ensure you have no issues with the upgrade, please execute the following to verify your configuration is correct.
- Verify the hostname/IP you used for your AD configuration. To do this, log into Rancher using a web browser as an admin and click Admin → Access Control. Note the
server
field to determine your configured hostname/IP for your AD server. - To verify your the configure hostname/IP for your TLS cert, you can execute the following command to determine the CN attribute:
openssl s_client -showcerts -connect domain.example.com:443
You should see something like:
subject=/OU=Domain Control Validated/CN=domain.example.com
Verify that the CN attribute matches with your configuredserver
field from the above step.
If the fields match, you are good to go. Nothing else is required.
If the fields do not match, please execute the following steps to correct it.
- Open a web browser and go to Rancher’s
settings
URL. This can be done by logging into Rancher as an admin and click API → Keys. You should see anEndpoint (v2-beta)
field. Take the value of that field and append/settings
. The final URL should look something likemy.rancher.url:8080/v2-beta/settings
. Launch this URL in your browser and you should see Rancher’s API browser. - Search for
api.auth.ldap.server
and click that setting to edit it. On the top right, you should be able to click anedit
button. Change the value of that to match the hostname/IP of the value found in your cert as identified by the CN attribute and click Show Request → Send Request to persist the value into Rancher’s DB. The response should show your new value.
Once this is completed and the hostname/IP matches your certs’ CN attribute, you should have no issues with AD login after upgrading to 1.6.8.
Enhancements
- Kubernetes 1.8.x Support - Rancher now supports the latest Kubernetes 1.8.3 version. One of the major highlight is the graduation of RBAC to stable and is now recommended for production use. Other major beta features getting more enhancements include the Workload API and CRD framework.
- HAProxy now supports draining of connections [#2777] - You can set a drain timeout for your services so that existing open connections to old containers in a service are drained before reloading haproxy.
- Clustered Mysql Support [#9329] - Clustered MySQL setups such as Percona is now supported.
- CLI - Added an option
--prune
in CLI forrancher up
to be able to remove services when upgrading [#7993]
Infrastructure Service Updates
When upgrading infrastructure services, please make sure to upgrade in the recommended order.
-
Network Services - v0.2.7
- New image:
rancher/network-manager:v0.7.18
,rancher/metadata:v0.9.5
- Fixed iptables rules reordering issue after docker daemon restart. [#8978, #9503]
- Added ability to log message if MTU mismatch is found.
- Added support for other network plugins.
- Option to disable CNI setup.
- Added ability to disable various syncs available.
- Added ability to avoid adding rancher internal search domains if “io.rancher.container.dns.priority” is None.
- Updated to include
stopping
containers [#10006]
- New image:
-
IPsec - 0.2.0
-
VXLAN - 0.3.0
The earlier version of this stack would cause a traffic disruption during upgrades, this version address to solve this problem. Also this version removes thecni-driver
service as a sidekick of thevxlan
container and makes it standalone.- New image:
rancher/net:v0.13.1
- Refactored to run in host network ns for performance improvements.
- Updated to include
stopping
containers [#10006] - Fixed an issue where when using scheduler IPs, the vxlan container may be re-scheduled and uses one of the scheduler IPs instead of the agent IP and cause network disruption [#9855]
- New image:
-
Kubernetes 1.8.3 - v1.8.3-rancher1
- New images:
rancher/k8s:v1.8.3-rancher1
,rancher/kubectld:v0.8.5
,rancher/kubernetes-agent:v0.6.6
- Added configurable value to service cluster IP cidr [#7694]
- Added Azure as a Cloud Provider [#8721]
- Fixed an issue where in Kubernetes adding a label to a host would remove an existing taint in the k8s node [#9500]
- Fixed an issue where Kubernetes Users with a auth protected private registry were unable to pull the
pause-amd64:3.0
image [#9790] - Fixed an issue where DNS errors were being logged [#9303]
- Updated to latest add-ons for Heapster, which fixed a memory leak in the previous version of influxDB [#9527]
Note: If upgrading from a k8s version prior to k8s v1.6, then you will need to re-generate any remote kubeconfig due to RBAC support.
- New images:
-
Container Crontab - v0.3.0
- New Image:
rancher/container-crontab:v0.3.0
- Fixed an issue where containers stopped during upgrade were being restarted by crontab [#8757].
- New Image:
-
Rancher EBS - v0.4.0
-
Route 53 - v0.7.7
- New Image:
rancher/external:v0.7.7
- AWS-SDK updated to
v1.12.19
- Added support for configuring number of max. retries of rate-limited Route53 API requests
- New Image:
Known Major Issues
- Kubernetes Users upgrading to Kubernetes 1.8: There is a bug in Kubernetes that causes all pods to restart after upgrade. Container spec hash changed. Container will be killed and recreated. · Issue #53644 · kubernetes/kubernetes · GitHub
Major Bug Fixes since v1.6.10
- Fixed an issue where health check enabled services would get recreated during IPSec upgrade [#10217]
- FIxed an issue where API keys stopped working when the Azure AD token expired [#9986]
- Fixed an issue where metadata service would increase CPU usage [#9957]
- Fixed an issue where exporting the docker compose file would fail with an error if it included secrets using the
mode
attribute [#9950] - Fixed an issue where cattle-debug logs were growing indefinitely [#9887]
- Fixed an issue where containers with the
io.rancher.container.network=true
label would override network modes for containers started within Rancher [#9700] - Fixed an issue where the Docker engine couldn’t be passed as an option for RancherOS [#9528]
- Fixed an issue where a load balancer listens on all IPs when using scheduler IPs [#9752]
- Fixed an issue where secrets were being lost during webhook triggered upgrades [#8714]
- Fixed an issue where AWS ELB catalog items were hitting a
max 20 ELB
limit [#7307] - Fixed an issue to be able to set up Rancher with external MySQL over SSL [#4199]