Release v2.0.7

@rancherio-gh-m rancherio-gh-m released this Aug 13, 2018 · 2 commits to master since this release

Release v2.0.7

Important

The default network selected when creating a Kubernetes cluster has been updated to canal with no network policies. With this change in default behavior, there are no network policy enforcements between projects, which means there is inter-project communication.

If you want to turn on network policies, which was the previous default behavior, then you would need to edit your cluster options to enable these network policies when deploying a cluster.

Versions

NOTE - Image Name Changes: Please note that as of v2.0.0, our images will be rancher/rancher and rancher/rancher-agent. If you are using v1.6, please continue to use rancher/server and rancher/agent.

  • rancher/rancher:v2.0.7
  • rancher/rancher-agent:v2.0.7

Rancher Server Tags

Rancher server has 2 different tags. For each major release tag, we will provide documentation for the specific version.

  • rancher/rancher: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/rancher:stable tag will be our latest stable release builds. This tag is the version that we recommend for production.

Please do not use releases with a rc{n} suffix. These rc builds are meant for the Rancher team to test builds.

Latest - v2.0.7 - rancher/rancher:latest

Stable - v2.0.6 - rancher/rancher:stable

Upgrades and Rollbacks

Rancher supports both upgrade and rollback starting with v2.0.2. Please note the version you would like to upgrade or rollback to change the Rancher version.

Any upgrade after v2.0.3, when scaling up workloads, new pods will be created [#14136] - In order to update scheduling rules for workloads [#13527], a new field was added to all workloads on update, which will cause any pods in workloads from previous versions to re-create.

Note: When rolling back, we are expecting you to rollback to the state at the time of your upgrade. Any changes post upgrade would not be reflected. In the case of rolling back using a Rancher single-node install, you must specify the exact version you want to change the Rancher version to, rather than using the default :latest tag.

Note: If you had the helm stable catalog enabled in v2.0.0, we've updated the catalog to start pointing directly to the kubernetes helm repo instead of an internal repo. Please delete the custom catalog that is now showing up and re-enable the helm stable. [#13582]

Enhancements

  • Performance Improvements [#14372, #14402, #14409] - In this release, we've added enhancements to improve the performance of Rancher.

  • Ability to turn on and off network policies for canal networking [#14462] - For new clusters, network policies are now off by default and we've exposed the ability to turn the feature on and off.

  • Support for Ping Federate [#11169] - Ping Federate has been implemented as an authentication provider and can be selected as an option.

  • Support for ADFS [#14609] - Ping Federate has been implemented as an authentication provider and can be selected as an option.

  • Ability to configure the default user role [#12737] - Rancher admins can now specify the global role(s) a user receives when they log in for the first time and what role(s) a user is assigned when they create a cluster or project.

  • Ability to Collect Audit Logs [#12733] - Rancher can now be configured to collect and expose via a REST API an audit log of all activities performed by users in the Rancher API.

  • System Project [#12706] - All clusters will now have a system project into which all Kubernetes and Rancher system namespaces will be place. This is to allow Rancher to properly manage these important namespaces.

  • Added Default Pod Security Policies [#12832] - There are now 2 default pod security policies in Rancher, restricted and unrestricted.

  • Added ability to deploy metrics server [#13745] - Clusters using RKE (custom nodes or node pools) have the ability to deploy a metrics server

  • Added additional fields for GKE and EKS [#14566, #13789] - New fields have been exposed for GKE and EKS to allow better control over cluster creation

  • Version Changes

    • Added Kubernetes 1.11 Support [#13837] and dropped Kubernetes 1.8 as an option during cluster creation [#14517]
    • Updated Docker Machine to v0.15.0
      • Adds cn-northwest support in for AWS [#11192]
    • NGINX ingress controller updated to v1.16 [#13294]
    • Helm updated to v2.9.1 [14023]

Known Major Issues

Major Bug Fixes since v2.0.6

  • Fixed an issue where project alerts using workload selectors were not project specific [#13183]
  • Fixed an issue where logging wasn't able to work if you had a custom docker root directory. You can now specify where the docker root directory is when creating your cluster [#13304]
  • Fixed an issue where there was no way to specify a namespace in catalog.yml files [#13519]
  • Fixed an issue where after upgrade, ingresses might have thrown 503s or inability to target new workloads [#13611]
  • Fixed an issue where defunct processes wouldn't be cleaned up [#13858]
  • Fixed an issue where you couldn't add a persistent volume with the local node disk option [#13864]
  • Fixed an issue where if you had multiple private registries, you couldn't clone or upgrade the workload to use a different private registry [#13872]
  • Fixed an issue where you couldn't use kubectl top in our kubectl shell [#14025]
  • Fixed an issue where subpaths for volume mounts were not being validated before creating workloads [#14061]
  • Fixed an issue where you couldn't change a worker and control plane node into a control plane only node [#14133]
  • Fixed an issue where service accounts were not getting the Pod Security Police role bindings assigned [#14441]
  • Fixed an issue where there was no easy way to disable the default nginx ingress controller [#14516]
  • Fixed an issue where you had to add the domain as part of service account username when configuring Active Directory [#14708]
  • Fixed an issue where cluster, apps/workloads could get stuck in deleting [#11991]
  • Fixed an issue where if one of the control planes was unavailable, then you couldn't add any worker or control plane nodes into the cluster [#13706]
  • Fixed an issue where kubelt containers are removed from worker nodes if duplicate binds are in the cluster config yaml [#14470]
  • Fixed an issue where adding members to a cluster with multiple custom roles were creating multiple user accounts and making it impossible for the user to log in [#14822]
  • Fixed an issue where control node taint might be missing on nodes after bringing up different nodes at different times with different roles [#14896]

Migrating from Rancher 1.6

Our next major milestone will be our 2.1 release that will include a tool that will convert Rancher Compose to Kubernetes YAML. This will help our existing Cattle users from having to start the migration from scratch. However, we know the biggest challenge will be having to leverage Cattle functionality in a Kubernetes environment as you deploy new workloads. We plan to also release a guide that will act as a cheatsheet for those that enjoy Cattle's simplicity and want to quickly create those workloads in Kubernetes.

Rancher CLI Downloads

https://github.com/rancher/cli/releases/tag/v2.0.4

v1.6.21

@cjellick cjellick released this Aug 7, 2018 · 1531 commits to master since this release

Release v1.6.21

Versions

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
  • Docker 17.12-ce/ee
  • Docker 18.03-ce/ee
  • Docker 18.06-ce/ee

Note: Kubernetes 1.11/1.10/1.9/1.8 supports Docker 1.12.6, 1.13.1 and 17.03.2.

Kubernetes Versions

List of images required to launch Kubernetes template:

  • rancher/k8s:v1.10.5-rancher1-4
  • rancher/etcd:v2.3.7-17
  • rancher/kubectld:v0.8.7
  • rancher/etc-host-updater:v0.0.3
  • rancher/kubernetes-agent:v0.6.9
  • rancher/kubernetes-auth:v0.0.8
  • rancher/lb-service-rancher:v0.9.4
  • busybox

For the list of versions for the Kubernetes add-ons embedded in the Rancher Kubernetes images, please refer to the kubernetes-package repo for the specific images and versions.

Note: If you have configured the aws cloud provider, tagging the cluster resources with a ClusterID is now required as of Kubernetes 1.10+. You should add tags to your EC2 instances before launching Kubernetes.

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 use releases with a rc{n} suffix. These rc builds are meant for the Rancher team to test builds.

Beta - v1.6.21 - rancher/server:latest

Stable - v1.6.21 - rancher/server:stable

Important - More Security

Starting with v1.6.19, we have updated a few components in Rancher to enhance security.

  • The zulu-openjdk package has now been updated to support JDK v8u172.
  • The etcd nodes that are installed when creating a kubernetes cluster are now defaulted to having etcd cluster TLS enabled.

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 is master.

  • Rollback Versions: We support rolling back to Rancher v1.6.18 from Rancher v1.6.21.

    • If you have upgraded to Kubernetes v1.10.5-rancher4 or v1.11.1-rancher1-3 or any version after these, there are some manual steps that need to occur to roll back to any version prior to these ones due to the updates for having etcd cluster with TLS enabled.

      1. Stop the kube-api service
      2. Exec into one of the etcd containers
      3. Run the following command. The output is in the following format: etcd_memeber_id: member_name peerURLs clientURLs.
        $ etcdctl member list
        
      4. You will need to run the following commands to update the cluster peer URLs from HTTPS to HTTP, and from names to IPs
      • replace - with . in the member_name to get the IP
      • run the member update command in the following format:
        etcdctl member update <etcd_member_id> <list of comma separated peerURL>
        
      1. After etcd has been updated, proceed with typical rollback steps.
    • Steps to Rollback:

      1. In the upgraded version the Admin -> Advanced Settings -> API values, update the upgrade.manager value to all.
      2. "Upgrade" Rancher server but pointing to the older version of Rancher (v1.6.18). This should include backing up your database and launching Rancher to point to your current database.
      3. Once Rancher starts up again, all infrastructure stacks will automatically rollback to the applicable version in v1.6.18.
      4. After your setup is back to its original state, update the upgrade.manager value back to the original value that you had (either mandatory or none).

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 configured server 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 an Endpoint (v2-beta) field. Take the value of that field and append /settings. The final URL should look something like my.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 an edit 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

None

Infrastructure Service Updates

When upgrading infrastructure services, please make sure to upgrade in the recommended order.

  • Kubernetes 1.10.5 - v1.10.5-rancher1-4-1

    • New images: rancher/etcd:v2.3.7-17
      • Fixed an issue where etcd could not start on clusters that used self-signed certificates [#14965]

    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.

    Note: If you have configured the aws cloudprovider, tagging the cluster resources with a ClusterID is now required. You should add tags to your EC2 instances before upgrading.

  • Kubernetes 1.11.1 - v1.11.1-rancher1-3-1

    • New images: rancher/etcd:v2.3.7-17
      • Fixed an issue where etcd could not start on clusters that used self-signed certificates [#14965]

    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.

    Note: If you have configured the aws cloudprovider, tagging the cluster resources with a ClusterID is now required. You should add tags to your EC2 instances before upgrading.

Known Major Issues

None

Major Bug Fixes since v1.6.20

  • Fixed an issue where etcd could not start on clusters that used self-signed certificates [#14965]

Rancher CLI Downloads

https://github.com/rancher/cli/releases/tag/v0.6.11

v1.6.20

@deniseschannon deniseschannon released this Jul 25, 2018 · 1531 commits to master since this release

Release v1.6.20

Important: This version is exactly the same as v1.6.19 except that it has rancher/agent:v1.2.11 instead of rancher/agent:v1.2.11-rc1.

Versions

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
  • Docker 17.12-ce/ee
  • Docker 18.03-ce/ee
  • Docker 18.06-ce/ee

Note: Kubernetes 1.11/1.10/1.9/1.8 supports Docker 1.12.6, 1.13.1 and 17.03.2.

Kubernetes Versions

List of images required to launch Kubernetes template:

  • rancher/k8s:v1.10.5-rancher1-4
  • rancher/etcd:v2.3.7-16
  • rancher/kubectld:v0.8.7
  • rancher/etc-host-updater:v0.0.3
  • rancher/kubernetes-agent:v0.6.9
  • rancher/kubernetes-auth:v0.0.8
  • rancher/lb-service-rancher:v0.9.4
  • busybox

For the list of versions for the Kubernetes add-ons embedded in the Rancher Kubernetes images, please refer to the kubernetes-package repo for the specific images and versions.

Note: If you have configured the aws cloud provider, tagging the cluster resources with a ClusterID is now required as of Kubernetes 1.10+. You should add tags to your EC2 instances before launching Kubernetes.

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 use releases with a rc{n} suffix. These rc builds are meant for the Rancher team to test builds.

Beta - v1.6.20 - rancher/server:latest

Stable - v1.6.18 - rancher/server:stable

Important - More Security

Starting with v1.6.19, we have updated a few components in Rancher to enhance security.

  • The zulu-openjdk package has now been updated to support JDK v8u172.
  • The etcd nodes that are installed when creating a kubernetes cluster are now defaulted to having etcd cluster TLS enabled.

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 is master.

  • Rollback Versions: We support rolling back to Rancher v1.6.18 from Rancher v1.6.20.

    • If you have upgraded to Kubernetes v1.10.5-rancher4 or v1.11.1-rancher1-3 or any version after these, there are some manual steps that need to occur to roll back to any version prior to these ones due to the updates for having etcd cluster with TLS enabled.

      1. Stop the kube-api service
      2. Exec into one of the etcd containers
      3. Run the following command. The output is in the following format: etcd_memeber_id: member_name peerURLs clientURLs.
        $ etcdctl member list
        
      4. You will need to run the following commands to update the cluster peer URLs from HTTPS to HTTP, and from names to IPs
      • replace - with . in the member_name to get the IP
      • run the member update command in the following format:
        etcdctl member update <etcd_member_id> <list of comma separated peerURL>
        
      1. After etcd has been updated, proceed with typical rollback steps.
    • Steps to Rollback:

      1. In the upgraded version the Admin -> Advanced Settings -> API values, update the upgrade.manager value to all.
      2. "Upgrade" Rancher server but pointing to the older version of Rancher (v1.6.18). This should include backing up your database and launching Rancher to point to your current database.
      3. Once Rancher starts up again, all infrastructure stacks will automatically rollback to the applicable version in v1.6.18.
      4. After your setup is back to its original state, update the upgrade.manager value back to the original value that you had (either mandatory or none).

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 configured server 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 an Endpoint (v2-beta) field. Take the value of that field and append /settings. The final URL should look something like my.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 an edit 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

Infrastructure Service Updates

When upgrading infrastructure services, please make sure to upgrade in the recommended order.

  • Kubernetes 1.10.5 - v1.10.5-rancher1-4

    • New images: rancher/k8s:v1.10.5-rancher1-4, rancher/etcd:v2.3.7-16``rancher/kubernetes-agent:v0.6.9, rancher/lb-service-rancher:v0.9.4
      • Fixed an issue where HPA wasn't working on default v1.10 deployment [#13221]
      • Fixed an issue where k8s ingress controller was not updating node IPs when there are a large number of ingresses on several hosts [#14380]
      • Added loglevel to kubernetes-agent and lb-service-rancher services to help with debugging [#12750]

    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.

    Note: If you have configured the aws cloudprovider, tagging the cluster resources with a ClusterID is now required. You should add tags to your EC2 instances before upgrading.

  • Kubernetes 1.11.1 - v1.11.1-rancher1-3

    • New images: rancher/k8s:v1.11.0-rancher1-3, rancher/etcd:v2.3.7-16, rancher/kubectld:v0.8.8, rancher/kubernetes-agent:v0.6.9, rancher/lb-service-rancher:v0.9.4

    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.

    Note: If you have configured the aws cloudprovider, tagging the cluster resources with a ClusterID is now required. You should add tags to your EC2 instances before upgrading.

  • Network Policy Manager - v0.0.4

    • New images: rancher/network-policy-manager:v0.2.8
    • Added loglevel to the service to help with debugging [#12750]
  • Network Services - v0.2.10

  • New images: rancher/network-manager:v0.7.22, rancher/metadata:v0.10.4, rancher/dns:v0.17.4
    • Fixed an issue with iptables rules when accessing expose port from self host. [#11724]
    • Added loglevel to the service to help with debugging [#12750]
  • IPsec - 0.2.5

    • New images: rancher/net:v0.13.17
    • Added loglevel to the service to help with debugging [#12750]
    • Removed connectivity check requirements during upgrades and changed it to be configurable [#13891]
    • Changed default connection check interval from 5 seconds to 10 seconds.
    • Changed default connection timeout from 1 seconds to 60 seconds.
  • Scheduler - v0.8.5

    • New images: rancher/scheduler:v0.8.5
    • Added loglevel to the service to help with debugging [#12750]
  • Healthcheck - v0.3.8

    • New images: rancher/healthcheck:v0.3.8
    • Added loglevel to the service to help with debugging [#12750]
  • EBS - 0.6.0

    • New images: rancher/storage-ebs:v0.9.7
    • Added support for volume partitions [#12106]
    • Added ability to specify snapshot by tag key and value pair [#14315]

Known Major Issues

Major Bug Fixes since v1.6.18

  • Fixed an issue where restricted users were unable to exec into containers that had any CAP_ADD by adding a new API setting allow.restricted.user.exec that can be set to true[#13886]
  • Fixed an issue with Rancher CLI was unable to work when setting memory limits [#14059]
  • Fixed an issue where AzureAD was showing admin fields when they are not required to authenticate and set up AzureAD [#11614]
  • Fixed a memory leak of rancher-agent [#14276]

Rancher CLI Downloads

https://github.com/rancher/cli/releases/tag/v0.6.11

Release v1.6.19

@deniseschannon deniseschannon released this Jul 25, 2018 · 1531 commits to master since this release

Release v1.6.19

Important: This version was packaged with rancher/agent:v1.2.11-rc1 instead of rancher/agent:v1.2.11. We have released v1.6.20 to address the incorrect agent image.

Versions

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
  • Docker 17.12-ce/ee
  • Docker 18.03-ce/ee
  • Docker 18.06-ce/ee

Note: Kubernetes 1.11/1.10/1.9/1.8 supports Docker 1.12.6, 1.13.1 and 17.03.2.

Kubernetes Versions

List of images required to launch Kubernetes template:

  • rancher/k8s:v1.10.5-rancher1-4
  • rancher/etcd:v2.3.7-16
  • rancher/kubectld:v0.8.7
  • rancher/etc-host-updater:v0.0.3
  • rancher/kubernetes-agent:v0.6.9
  • rancher/kubernetes-auth:v0.0.8
  • rancher/lb-service-rancher:v0.9.4
  • busybox

For the list of versions for the Kubernetes add-ons embedded in the Rancher Kubernetes images, please refer to the kubernetes-package repo for the specific images and versions.

Note: If you have configured the aws cloud provider, tagging the cluster resources with a ClusterID is now required as of Kubernetes 1.10+. You should add tags to your EC2 instances before launching Kubernetes.

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 use releases with a rc{n} suffix. These rc builds are meant for the Rancher team to test builds.

Beta - v1.6.19 - rancher/server:latest

Stable - v1.6.18 - rancher/server:stable

Important - More Security

Starting with v1.6.19, we have updated a few components in Rancher to enhance security.

  • The zulu-openjdk package has now been updated to support JDK v8u172.
  • The etcd nodes that are installed when creating a kubernetes cluster are now defaulted to having etcd cluster TLS enabled.

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 is master.

  • Rollback Versions: We support rolling back to Rancher v1.6.18 from Rancher v1.6.19.

    • If you have upgraded to Kubernetes v1.10.5-rancher4 or v1.11.1-rancher1-3 or any version after these, there are some manual steps that need to occur to roll back to any version prior to these ones due to the updates for having etcd cluster with TLS enabled.

      1. Stop the kube-api service
      2. Exec into one of the etcd containers
      3. Run the following command. The output is in the following format: etcd_memeber_id: member_name peerURLs clientURLs.
        $ etcdctl member list
        
      4. You will need to run the following commands to update the cluster peer URLs from HTTPS to HTTP, and from names to IPs
      • replace - with . in the member_name to get the IP
      • run the member update command in the following format:
        etcdctl member update <etcd_member_id> <list of comma separated peerURL>
        
      1. After etcd has been updated, proceed with typical rollback steps.
    • Steps to Rollback:

      1. In the upgraded version the Admin -> Advanced Settings -> API values, update the upgrade.manager value to all.
      2. "Upgrade" Rancher server but pointing to the older version of Rancher (v1.6.18). This should include backing up your database and launching Rancher to point to your current database.
      3. Once Rancher starts up again, all infrastructure stacks will automatically rollback to the applicable version in v1.6.18.
      4. After your setup is back to its original state, update the upgrade.manager value back to the original value that you had (either mandatory or none).

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 configured server 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 an Endpoint (v2-beta) field. Take the value of that field and append /settings. The final URL should look something like my.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 an edit 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

Infrastructure Service Updates

When upgrading infrastructure services, please make sure to upgrade in the recommended order.

  • Kubernetes 1.10.5 - v1.10.5-rancher1-4

    • New images: rancher/k8s:v1.10.5-rancher1-4, rancher/etcd:v2.3.7-16``rancher/kubernetes-agent:v0.6.9, rancher/lb-service-rancher:v0.9.4
      • Fixed an issue where HPA wasn't working on default v1.10 deployment [#13221]
      • Fixed an issue where k8s ingress controller was not updating node IPs when there are a large number of ingresses on several hosts [#14380]
      • Added loglevel to kubernetes-agent and lb-service-rancher services to help with debugging [#12750]

    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.

    Note: If you have configured the aws cloudprovider, tagging the cluster resources with a ClusterID is now required. You should add tags to your EC2 instances before upgrading.

  • Kubernetes 1.11.1 - v1.11.1-rancher1-3

    • New images: rancher/k8s:v1.11.0-rancher1-3, rancher/etcd:v2.3.7-16, rancher/kubectld:v0.8.8, rancher/kubernetes-agent:v0.6.9, rancher/lb-service-rancher:v0.9.4

    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.

    Note: If you have configured the aws cloudprovider, tagging the cluster resources with a ClusterID is now required. You should add tags to your EC2 instances before upgrading.

  • Network Policy Manager - v0.0.4

    • New images: rancher/network-policy-manager:v0.2.8
    • Added loglevel to the service to help with debugging [#12750]
  • Network Services - v0.2.10

  • New images: rancher/network-manager:v0.7.22, rancher/metadata:v0.10.4, rancher/dns:v0.17.4
    • Fixed an issue with iptables rules when accessing expose port from self host. [#11724]
    • Added loglevel to the service to help with debugging [#12750]
  • IPsec - 0.2.5

    • New images: rancher/net:v0.13.17
    • Added loglevel to the service to help with debugging [#12750]
    • Removed connectivity check requirements during upgrades and changed it to be configurable [#13891]
    • Changed default connection check interval from 5 seconds to 10 seconds.
    • Changed default connection timeout from 1 seconds to 60 seconds.
  • Scheduler - v0.8.5

    • New images: rancher/scheduler:v0.8.5
    • Added loglevel to the service to help with debugging [#12750]
  • Healthcheck - v0.3.8

    • New images: rancher/healthcheck:v0.3.8
    • Added loglevel to the service to help with debugging [#12750]
  • EBS - 0.6.0

    • New images: rancher/storage-ebs:v0.9.7
    • Added support for volume partitions [#12106]
    • Added ability to specify snapshot by tag key and value pair [#14315]

Known Major Issues

Major Bug Fixes since v1.6.18

  • Fixed an issue where restricted users were unable to exec into containers that had any CAP_ADD by adding a new API setting allow.restricted.user.exec that can be set to true[#13886]
  • Fixed an issue with Rancher CLI was unable to work when setting memory limits [#14059]
  • Fixed an issue where AzureAD was showing admin fields when they are not required to authenticate and set up AzureAD [#11614]
  • Fixed a memory leak of rancher-agent [#14276]

Rancher CLI Downloads

https://github.com/rancher/cli/releases/tag/v0.6.11