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

update with master content resolving merge conflicts

Browse Source
This commit is contained in:
MAKOSCAFEE
2019-06-19 19:10:18 +03:00
parent b42f019aae 42cbe1256e
commit 8781518d32
1439 changed files with 70927 additions and 43295 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
+6 -5
View File
@@ -125,8 +125,8 @@ must be mounted as a
in the plugin's
[PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core).
Kubernetes device plugin support is still in alpha. As development continues, its API version can
change in incompatible ways. We recommend that device plugin developers do the following:
Kubernetes device plugin support is in beta. As development continues, its API version can
change. We recommend that device plugin developers do the following:
* Watch for changes in future releases.
* Support multiple versions of the device plugin API for backward/forward compatibility.
@@ -148,16 +148,16 @@ The kubelet provides a gRPC service to enable discovery of in-use devices, and t
for these devices:
```gRPC
// PodResources is a service provided by the kubelet that provides information about the
// PodResourcesLister is a service provided by the kubelet that provides information about the
// node resources consumed by pods and containers on the node
service PodResources {
service PodResourcesLister {
rpc List(ListPodResourcesRequest) returns (ListPodResourcesResponse) {}
}
```
The gRPC service is served over a unix socket at `/var/lib/kubelet/pod-resources/kubelet.sock`.
Monitoring agents for device plugin resources can be deployed as a daemon, or as a DaemonSet.
The cannonical directory `/var/lib/kubelet/pod-resources` requires privileged access, so monitoring
The canonical directory `/var/lib/kubelet/pod-resources` requires privileged access, so monitoring
agents must run in a privileged security context. If a device monitoring agent is running as a
DaemonSet, `/var/lib/kubelet/pod-resources` must be mounted as a
[Volume](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volume-v1-core)
@@ -179,6 +179,7 @@ For examples of device plugin implementations, see:
* The [AMD GPU device plugin](https://github.com/RadeonOpenCompute/k8s-device-plugin)
* The [SRIOV Network device plugin](https://github.com/intel/sriov-network-device-plugin)
* The [Intel device plugins](https://github.com/intel/intel-device-plugins-for-kubernetes) for GPU, FPGA and QuickAssist devices
* The [Xilinx FPGA device plugins](https://github.com/Xilinx/FPGA_as_a_Service/tree/master/k8s-fpga-device-plugin/trunk) for Xilinx FPGA devices
{{% /capture %}}
content/en/docs/concepts/extend-kubernetes/extend-cluster.md
-5
View File
@@ -156,7 +156,6 @@ After a request is authorized, if it is a write operation, it also goes through
* The [Image Policy webhook](/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook) restricts what images can be run in containers.
* To make arbitrary admission control decisions, a general [Admission webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) can be used. Admission Webhooks can reject creations or updates.
* [Initializers](/docs/reference/access-authn-authz/extensible-admission-controllers/#initializers) are controllers that can modify objects before they are created. Initializers can modify initial object creations but cannot affect updates to objects. Initializers can also reject objects.
## Infrastructure Extensions
@@ -210,7 +209,3 @@ the nodes chosen for a pod.
* [List of Operators](https://github.com/operator-framework/awesome-operators)
{{% /capture %}}