Keep some sentences in third person
This commit is contained in:
parent
8dcebae500
commit
0398ce4e27
|
@ -23,29 +23,29 @@ A CSI Driver in Kubernetes has two main components: a controller plugin which ru
|
||||||
|
|
||||||
When a workload that uses persistent volumes is scheduled, it'll go through a sequence of steps defined in the [CSI Spec](https://github.com/container-storage-interface/spec/blob/master/spec.md). First, the workload will be scheduled to run on a node. Then the controller component of a CSI Driver will attach the persistent volume to the node. Finally the node component of a CSI Driver will mount the persistent volume on the node.
|
When a workload that uses persistent volumes is scheduled, it'll go through a sequence of steps defined in the [CSI Spec](https://github.com/container-storage-interface/spec/blob/master/spec.md). First, the workload will be scheduled to run on a node. Then the controller component of a CSI Driver will attach the persistent volume to the node. Finally the node component of a CSI Driver will mount the persistent volume on the node.
|
||||||
|
|
||||||
The node component of a CSI Driver needs to run on Windows nodes to support Windows workloads. Various privileged operations like scanning of disk devices, mounting of file systems, etc. cannot be done from a containerized application running on Windows nodes yet (Windows Host Process is available in kubernetes 1.22 as alpha). However, we can perform these operations through a binary (CSI Proxy) that's pre-installed on the Window nodes. CSI Proxy has a client-server architecture and allows CSI drivers to issue privileged storage operations through a gRPC interface exposed over named pipes created during the startup of CSI Proxy.
|
The node component of a CSI Driver needs to run on Windows nodes to support Windows workloads. Various privileged operations like scanning of disk devices, mounting of file systems, etc. cannot be done from a containerized application running on Windows nodes yet ([Windows HostProcess containers](https://github.com/kubernetes/enhancements/issues/1981) introduced in Kubernetes 1.22 as alpha enable functionalities that require host access like the operations mentioned before). However, we can perform these operations through a binary (CSI Proxy) that's pre-installed on the Window nodes. CSI Proxy has a client-server architecture and allows CSI drivers to issue privileged storage operations through a gRPC interface exposed over named pipes created during the startup of CSI Proxy.
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
## CSI Proxy reaches GA
|
## CSI Proxy reaches GA
|
||||||
|
|
||||||
Since the introduction of the [CSI Proxy KEP](https://github.com/kubernetes/enhancements/tree/master/keps/sig-windows/1122-windows-csi-support), storage vendors integrated CSI Proxy into their CSI Drivers and provided feedback. We learned about use cases where we needed new APIs, as well as getting bug reports, bug fixes and documentation updates.
|
The CSI Proxy development team has worked closely with storage vendors, many of whom started integrating CSI Proxy into their CSI Drivers and provided feedback as early as CSI Proxy design proposal. This cooperation uncovered use cases where additional APIs were needed, found bugs, and areas for documentation improvement.
|
||||||
|
|
||||||
We've updated the [KEP](https://github.com/kubernetes/enhancements/pull/2737) which now reflects the current CSI Proxy architecture and added additional [development documentation](https://github.com/kubernetes-csi/csi-proxy/blob/master/docs/DEVELOPMENT.md) for people that want to contribute with new features or bug fixes.
|
The CSI Proxy design [KEP](https://github.com/kubernetes/enhancements/pull/2737) has been updated to reflect the current CSI Proxy architecture. Additional [development documentation](https://github.com/kubernetes-csi/csi-proxy/blob/master/docs/DEVELOPMENT.md) is included for contributors interested in helping with new features or bug fixes.
|
||||||
|
|
||||||
Before we reached GA we wanted to make sure that our API is simple and consistent. We went through an extensive [API review](https://docs.google.com/document/d/1sBP8f_mwV0N_xRRQQGDwHZpU_nTHtpFxdi7LKSUtgX0/edit#heading=h.inwrahdkakje) of the v1beta API groups where we made sure that the CSI Proxy API methods and messages are consistent with the naming conventions defined in the [CSI Spec](https://github.com/container-storage-interface/spec/blob/master/spec.md). As part of this effort we're graduating the [Disk](https://github.com/kubernetes-csi/csi-proxy/blob/master/docs/apis/disk_v1.md), [Filesystem](https://github.com/kubernetes-csi/csi-proxy/blob/master/docs/apis/filesystem_v1.md), [SMB](https://github.com/kubernetes-csi/csi-proxy/blob/master/docs/apis/smb_v1.md) and [Volume](https://github.com/kubernetes-csi/csi-proxy/blob/master/docs/apis/volume_v1.md) API groups to v1.
|
Before we reached GA we wanted to make sure that our API is simple and consistent. We went through an extensive [API review](https://docs.google.com/document/d/1sBP8f_mwV0N_xRRQQGDwHZpU_nTHtpFxdi7LKSUtgX0/edit#heading=h.inwrahdkakje) of the v1beta API groups where we made sure that the CSI Proxy API methods and messages are consistent with the naming conventions defined in the [CSI Spec](https://github.com/container-storage-interface/spec/blob/master/spec.md). As part of this effort we're graduating the [Disk](https://github.com/kubernetes-csi/csi-proxy/blob/master/docs/apis/disk_v1.md), [Filesystem](https://github.com/kubernetes-csi/csi-proxy/blob/master/docs/apis/filesystem_v1.md), [SMB](https://github.com/kubernetes-csi/csi-proxy/blob/master/docs/apis/smb_v1.md) and [Volume](https://github.com/kubernetes-csi/csi-proxy/blob/master/docs/apis/volume_v1.md) API groups to v1.
|
||||||
|
|
||||||
CSI Proxy is compatible with all the previous v1betaX releases. The `csi-proxy.exe` binary deployed on Windows nodes still serves requests from v1betaX clients thanks to the autogenerated conversion layer that transforms any versioned client request to a version-agnostic request that the server can process. We added several [integration tests](https://github.com/kubernetes-csi/csi-proxy/tree/v1.0.0/integrationtests) for all the API versions of the API groups that are graduating to v1 to ensure that CSI Proxy is backwards compatible.
|
CSI Proxy v1 is compatible with all the previous v1betaX releases. The GA `csi-proxy.exe` binary can handle requests from v1betaX clients thanks to the autogenerated conversion layer that transforms any versioned client request to a version-agnostic request that the server can process. Several [integration tests](https://github.com/kubernetes-csi/csi-proxy/tree/v1.0.0/integrationtests) were added for all the API versions of the API groups that are graduating to v1 to ensure that CSI Proxy is backwards compatible.
|
||||||
|
|
||||||
We've also considered the scenario of a version drift between CSI Proxy and the CSI Drivers that interact with it and provided a way for CSI Drivers to handle multiple versions of CSI Proxy for a smooth upgrade to v1. [For example](https://github.com/kubernetes-sigs/gcp-compute-persistent-disk-csi-driver/pull/738), the GCE PD CSI Driver will use the CSI Proxy client libraries to connect to the v1 API first, if the connection is unsuccessful because the v1 version is not installed it'll connect to the v1beta API.
|
Version drift between CSI Proxy and the CSI Drivers that interact with it was also carefully considered. A [connection fallback mechanism](https://github.com/kubernetes-csi/csi-proxy/pull/124) has been provided for CSI Drivers to handle multiple versions of CSI Proxy for a smooth upgrade to v1. This allows CSI Drivers, like the GCE PD CSI Driver, [to recognize which version of the CSI Proxy binary is running](https://github.com/kubernetes-sigs/gcp-compute-persistent-disk-csi-driver/pull/738) and handle multiple versions of the CSI Proxy binary deployed on the node.
|
||||||
|
|
||||||
CSI Proxy v1 is already being used by many CSI Drivers, such as the [AWS EBS CSI Driver](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/pull/966), [Azure Disk CSI Driver](https://github.com/kubernetes-sigs/azuredisk-csi-driver/pull/919), [GCE PD CSI Driver](https://github.com/kubernetes-sigs/gcp-compute-persistent-disk-csi-driver/pull/738) and [SMB CSI Driver](https://github.com/kubernetes-csi/csi-driver-smb/pull/319).
|
CSI Proxy v1 is already being used by many CSI Drivers, including the [AWS EBS CSI Driver](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/pull/966), [Azure Disk CSI Driver](https://github.com/kubernetes-sigs/azuredisk-csi-driver/pull/919), [GCE PD CSI Driver](https://github.com/kubernetes-sigs/gcp-compute-persistent-disk-csi-driver/pull/738), and [SMB CSI Driver](https://github.com/kubernetes-csi/csi-driver-smb/pull/319).
|
||||||
|
|
||||||
## Future plans
|
## Future plans
|
||||||
|
|
||||||
We're very excited for the future of CSI Proxy. With the upcoming [support for privileged Windows containers](https://github.com/kubernetes/enhancements/issues/1981), we plan to use CSI Proxy as a library in CSI Drivers in addition to the current client/server design. This will allow us to iterate faster on new features because the `csi-proxy.exe` binary will no longer be needed.
|
We're very excited for the future of CSI Proxy. With the upcoming [Windows HostProcess containers](https://github.com/kubernetes/enhancements/issues/1981), we are considering converting the CSI Proxy in to a library consumed by CSI Drivers in addition to the current client/server design. This will allow us to iterate faster on new features because the `csi-proxy.exe` binary will no longer be needed.
|
||||||
|
|
||||||
Support for the [System API](https://github.com/kubernetes-csi/csi-proxy/tree/v1.0.0/client/api/system/v1alpha1) and the [iSCSI API](https://github.com/kubernetes-csi/csi-proxy/tree/v1.0.0/client/api/iscsi/v1alpha2) is in the alpha stage, we plan to make additional enhancements before graduating them to v1.
|
Windows system APIs to get additional information from the Windows nodes and support to mount iSCSI targets in Windows nodes are available as alpha APIs in the [System API](https://github.com/kubernetes-csi/csi-proxy/tree/v1.0.0/client/api/system/v1alpha1) and the [iSCSI API](https://github.com/kubernetes-csi/csi-proxy/tree/v1.0.0/client/api/iscsi/v1alpha2), these APIs will continue to be improved before we graduate them to v1.
|
||||||
|
|
||||||
## How to get involved?
|
## How to get involved?
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue