whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge remote-tracking branch 'upstream/master' into merged-master-dev-1.16

Browse Source
This commit is contained in:
simplytunde
2019-09-17 22:15:57 -05:00
parent 234ff08588 67c20b3d37
commit e95ffa68fd
34 changed files with 584 additions and 108 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/blog/_posts/2019-01-17-update-volume-snapshot-alpha.md
+1 -1
View File
@@ -132,7 +132,7 @@ If a user deletes a `VolumeSnapshot` API object in active use by a PVC, the `Vol
## Which volume plugins support Kubernetes Snapshots?
Snapshots are only supported for CSI drivers (not for in-tree or Flexvolume). To use the Kubernetes snapshots feature, ensure that a CSI Driver that implements snapshots is deployed on your cluster.
Snapshots are only supported for CSI drivers (not for in-tree or FlexVolume). To use the Kubernetes snapshots feature, ensure that a CSI Driver that implements snapshots is deployed on your cluster.
As of the publishing of this blog post, the following CSI drivers support snapshots:
content/en/blog/_posts/2019-03-22-e2e-testing-for-everyone.md
+1 -1
View File
@@ -8,7 +8,7 @@ date: 2019-03-22
More and more components that used to be part of Kubernetes are now
being developed outside of Kubernetes. For example, storage drivers
used to be compiled into Kubernetes binaries, then were moved into
[stand-alone Flexvolume
[stand-alone FlexVolume
binaries](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md)
on the host, and now are delivered as [Container Storage Interface
(CSI) drivers](https://github.com/container-storage-interface/spec)
content/en/blog/_posts/2019-07-18-some-apis-are-being-deprecated.md
+14 -23
View File
@@ -10,32 +10,23 @@ slug: api-deprecations-in-1-16
As the Kubernetes API evolves, APIs are periodically reorganized or upgraded.
When APIs evolve, the old API is deprecated and eventually removed.
The 1.16 release will deprecate APIs for four services:
The **v1.16** release will stop serving the following deprecated API versions in favor of newer and more stable API versions:
* NetworkPolicy
* PodSecurityPolicy
* DaemonSet, Deployment, StatefulSet, and ReplicaSet
* Ingress
* NetworkPolicy (in the **extensions/v1beta1** API group)
* Migrate to use the **networking.k8s.io/v1** API, available since v1.8.
Existing persisted data can be retrieved/updated via the **networking.k8s.io/v1** API.
* PodSecurityPolicy (in the **extensions/v1beta1** API group)
* Migrate to use the **policy/v1beta1** API, available since v1.10.
Existing persisted data can be retrieved/updated via the **policy/v1beta1** API.
* DaemonSet, Deployment, StatefulSet, and ReplicaSet (in the **extensions/v1beta1** and **apps/v1beta2** API groups)
* Migrate to use the **apps/v1** API, available since v1.9.
Existing persisted data can be retrieved/updated via the **apps/v1** API.
None of these resources will be removed from Kubernetes or deprecated in any way.
However, to continue using these resources, you must use a current version of
the Kubernetes API.
The **v1.20** release will stop serving the following deprecated API versions in favor of newer and more stable API versions:
# Migration Details
* NetworkPolicy: will no longer be served from **extensions/v1beta1** in **v1.16**.
* Migrate to the networking.k8s.io/v1 API, available since v1.8. Existing persisted
data can be retrieved/updated via the networking.k8s.io/v1 API.
* PodSecurityPolicy: will no longer be served from **extensions/v1beta1** in **v1.16**.
* Migrate to the policy/v1beta1 API, available since v1.10. Existing persisted
data can be retrieved/updated via the policy/v1beta1 API.
* DaemonSet, Deployment, StatefulSet, and ReplicaSet: will no longer be served
from **extensions/v1beta1**, **apps/v1beta1**, or **apps/v1beta2** in **v1.16**.
* Migrate to the apps/v1 API, available since v1.9. Existing persisted data
can be retrieved/updated via the apps/v1 API.
* Ingress: will no longer be served from **extensions/v1beta1** in **v1.18**.
* Migrate to the networking.k8s.io/v1beta1 API, serving Ingress since v1.14.
Existing persisted data can be retrieved/updated via the networking.k8s.io/v1beta1 API.
* Ingress (in the **extensions/v1beta1** API group)
* Migrate to use the **networking.k8s.io/v1beta1** API, serving Ingress since v1.14.
Existing persisted data can be retrieved/updated via the **networking.k8s.io/v1beta1** API.
# What To Do
content/en/blog/_posts/2019-08-30-announcing-etcd-3.4.md
+1 -1
View File
@@ -18,7 +18,7 @@ etcd v3.4 includes a number of performance improvements for large scale Kubernet
In particular, etcd experienced performance issues with a large number of concurrent read transactions even when there is no write (e.g. `“read-only range request ... took too long to execute”`). Previously, the storage backend commit operation on pending writes blocks incoming read transactions, even when there was no pending write. Now, the commit [does not block reads](https://github.com/etcd-io/etcd/pull/9296) which improve long-running read transaction performance.
We further made [backend read transactions fully concurrent](https://github.com/etcd-io/etcd/pull/10523). Previously, ongoing long-running read transactions block writes and upcoming reads. With this change, write throughput is increased by 70% and P99 write latency is reduced by 90% in the presence of long-running reads. We also ran [Kubernetes 5000-node scalability test on GCE](https://prow.k8s.io/view/gcs/kubernetes-jenkins/logs/ci-kubernetes-e2e-gce-scale-performance/1130745634945503235) with this change and observed similar improvements. For example, in the very beginning of the test where there are a lot of long-running “LIST pods”, the P99 latency of “POST clusterrolebindings” is [reduced by 97.4%](https://github.com/etcd-io/etcd/pull/10523#issuecomment-499262001). This non-blocking read transaction is now [used for compaction](https://github.com/etcd-io/etcd/pull/11034), which, combined with the reduced compaction batch size, reduces the P99 server request latency during compaction.
We further made [backend read transactions fully concurrent](https://github.com/etcd-io/etcd/pull/10523). Previously, ongoing long-running read transactions block writes and upcoming reads. With this change, write throughput is increased by 70% and P99 write latency is reduced by 90% in the presence of long-running reads. We also ran [Kubernetes 5000-node scalability test on GCE](https://prow.k8s.io/view/gcs/kubernetes-jenkins/logs/ci-kubernetes-e2e-gce-scale-performance/1130745634945503235) with this change and observed similar improvements. For example, in the very beginning of the test where there are a lot of long-running “LIST pods”, the P99 latency of “POST clusterrolebindings” is [reduced by 97.4%](https://github.com/etcd-io/etcd/pull/10523#issuecomment-499262001).
More improvements have been made to lease storage. We enhanced [lease expire/revoke performance](https://github.com/etcd-io/etcd/pull/9418) by storing lease objects more efficiently, and made [lease look-up operation non-blocking](https://github.com/etcd-io/etcd/pull/9229) with current lease grant/revoke operation. And etcd v3.4 introduces [lease checkpoint](https://github.com/etcd-io/etcd/pull/9924) as an experimental feature to persist remaining time-to-live values through consensus. This ensures short-lived lease objects are not auto-renewed after leadership election. This also prevents lease object pile-up when the time-to-live value is relatively large (e.g. [1-hour TTL never expired in Kubernetes use case](https://github.com/kubernetes/kubernetes/issues/65497)).