> fix some typos
This commit is contained in:
parent
b69895b10a
commit
f73479d17b
|
@ -653,7 +653,7 @@ kubectl run say-fruit --image=busybox \
|
|||
will all run 3 pods in parallel. Index 0 pod will log:
|
||||
|
||||
```
|
||||
Have a nice grenn apple
|
||||
Have a nice green apple
|
||||
```
|
||||
|
||||
and so on.
|
||||
|
|
|
@ -155,7 +155,7 @@ Existing behavior is unchanged for claims that do not specify
|
|||
|
||||
External provisioner must have these features:
|
||||
|
||||
* It MUST have a distinct name, following Kubernetenes plugin naming scheme
|
||||
* It MUST have a distinct name, following Kubernetes plugin naming scheme
|
||||
`<vendor name>/<provisioner name>`, e.g. `gluster.org/gluster-volume`.
|
||||
|
||||
* The provisioner SHOULD send events on a claim to report any errors
|
||||
|
|
|
@ -133,7 +133,7 @@ This level of the Cluster Management API describes the global configuration of a
|
|||
|
||||
Given the recent efforts of SIG Cluster Lifecycle to make kubeadm the de facto standard toolkit for cloud- and vendor-agnostic cluster initialization, and because kubeadm has [an existing API](https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/apis/kubeadm/v1alpha1/types.go) to define the global configuration for a cluster, it makes sense to coalesce the global portion of the Cluster API with the API used by “kubeadm init” to configure a cluster master.
|
||||
|
||||
A current goal is to make these APIs as cloud-agnostic as possible, so that the entire definition of a Cluster could remain reasonably in-sync across different deployments potentially in different cloud providers, which would help enable hybrid usecases where it’s desirable to have key configuration stay in sync across different clusters potentially in different clouds/environments. However, this goal is balanced against making the APIs coherent and useable, which strict separation may harm.
|
||||
A current goal is to make these APIs as cloud-agnostic as possible, so that the entire definition of a Cluster could remain reasonably in-sync across different deployments potentially in different cloud providers, which would help enable hybrid usecases where it’s desirable to have key configuration stay in sync across different clusters potentially in different clouds/environments. However, this goal is balanced against making the APIs coherent and usable, which strict separation may harm.
|
||||
|
||||
The full types for this API can be seen and were initially discussed in [kube-deploy#306](https://github.com/kubernetes/kube-deploy/pull/306).
|
||||
|
||||
|
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
- Michelle Noorali gave an introduction
|
||||
- Ben Hall, founder of katacoda, did a demo of [katacoda](https://www.katacoda.com/)
|
||||
- Katacoda is an interactive learning platoform for software engineers.
|
||||
- Katacoda is an interactive learning platform for software engineers.
|
||||
- Ben showed off the current lessons on Kubernetes which are available now.
|
||||
- Ben also talked about how companies/people can make their own interactive lessons and embed them.
|
||||
- Contact Ben on [Twitter](https://twitter.com/Ben_Hall): @Ben_Hall
|
||||
|
|
Loading…
Reference in New Issue