- [Server Binaries](#server-binaries-12)
    - [Node Binaries](#node-binaries-12)
- [Kubernetes v1.15 Release Notes](#kubernetes-v115-release-notes)
  - [1.15 What’s New](#115-what’s-new)
    - [Continuous Improvement](#continuous-improvement)
    - [Extensibility](#extensibility)
  - [Extensibility around core Kubernetes APIs](#extensibility-around-core-kubernetes-apis)

### SIG Autoscaling

[SIG Autoscaling][] is responsible for autoscaling-related components,
such as the Horizontal Pod Autoscaler and Cluster Autoscaler.

For the 1.8 release, SIG Autoscaling continued to focus on stabilizing
features introduced in previous releases: the new version of the
Horizontal Pod Autoscaler API, which supports custom metrics, and

- Client-go/reflector: warns when the bookmark event for initial events hasn't been received ([#124614](https://github.com/kubernetes/kubernetes/pull/124614), [@p0lyn0mial](https://github.com/p0lyn0mial)) [SIG API Machinery]
- Continued streaming kubelet logs when the CRI server of the runtime was unavailable. ([#124025](https://github.com/kubernetes/kubernetes/pull/124025), [@saschagrunert](https://github.com/saschagrunert)) [SIG Node]

Linux kernel cgroups v2 API was declared stable. With some distributions now defaulting to this API, Kubernetes must support it to continue operating on those distributions. cgroups v2 offers several improvements over cgroups v1, for more information see the [cgroups v2](https://kubernetes.io/docs/concepts/architecture/cgroups/) documentation. While cgroups v1 will continue to be supported, this enhancement puts Kubernetes to be ready for eventual deprecation and replacement in favor of v2.

...

		}
	}
</pre>

<h3 id="Continue_statements">Continue statements</h3>

<p>
A "continue" statement begins the next iteration of the
innermost enclosing <a href="#For_statements">"for" loop</a>
by advancing control to the end of the loop block.
The "for" loop must be within the same function.
</p>

<pre class="ebnf">
ContinueStmt = "continue" [ Label ] .
</pre>

<p>

- Upon receiving a LIST request with an expired continue token, the apiserver now returns a continue token together with the 410 "the from parameter is too old" error. If the client does not care about getting a list from a consistent snapshot, the client can use this token to continue listing from the next key, but the returned chunk will be from the latest snapshot. ([#67284](https://github.com/kubernetes/kubernetes/pull/67284),...

### Windows

cache sync failure. This fix allows the garbage collector to eventually continue garbage collecting other resources if a given resource cannot be listed or watched. Any objects in the unsynced resource type with owner references with `blockOwnerDeletion: true` will not be known to the garbage collector. Use of `blockOwnerDeletion` has always been best-effort and racy on startup and object creation. With this fix, it continues to be best-effort for resources that cannot be synced by the garbage collector...

- If `kubeadm reset` finds no etcd member ID for the peer it removes during the `remove-etcd-member` phase, it continues immediately to other phases, instead of retrying the phase for up to 3 minutes before continuing. ([#117948](https://github.com/kubernetes/kubernetes/pull/117948), [@dlipovetsky](https://github.com/dlipovetsky)) [SIG Cluster Lifecycle]

## **External Dependency Version Information**