Merge pull request #1222 from mattnworb/mattbrown/book-grammar-fixes

docs/book: small grammar/spelling tweaks

Author: k8s-ci-robot

docs/book/src/cronjob-tutorial/api-design.md

@@ -17,7 +17,7 @@ machines.  You've probably noticed them when specifying resources requests
 and limits on pods in Kubernetes.
 
 They conceptually work similar to floating point numbers: they have
-a significand, base, and exponent.  Their serialize, human readable for
+a significand, base, and exponent. Their serializable and human readable format
 uses whole numbers and suffixes to specify values much the way we describe
 computer storage.
 

docs/book/src/cronjob-tutorial/running-webhook.md

@@ -26,7 +26,7 @@ You don't need to push the image to a remote container registry if you are using
 a kind cluster. You can directly load your local image to your kind cluster:
 
 ```bash
-kind load docker-image your-image-namge:your-tag
+kind load docker-image your-image-name:your-tag
 ```
 
 ## Deploy Webhooks

docs/book/src/cronjob-tutorial/testdata/emptyapi.go

@@ -26,7 +26,7 @@ import (
 )
 
 /*
-Next, we get types for the Spec and Status of our Kind.  Kubernetes functions
+Next, we define types for the Spec and Status of our Kind.  Kubernetes functions
 by reconciling desired state (`Spec`) with actual cluster state (other objects'
 `Status`) and external state, and then recording what it observed (`Status`).
 Thus, every *functional* object includes spec and status.  A few types, like
@@ -49,15 +49,15 @@ type CronJobStatus struct {
 }
 
 /*
-Next, we get the types corresponding to actual Kinds, `CronJob` and `CronJobList`.
+Next, we define the types corresponding to actual Kinds, `CronJob` and `CronJobList`.
 `CronJob` is our root type, and describes the `CronJob` kind.  Like all Kubernetes objects, it contains
 `TypeMeta` (which describes API version and Kind), and also contains `ObjectMeta`, which holds things
 like name, namespace, and labels.
 
 `CronJobList` is simply a container for multiple `CronJob`s.  It's the Kind used in bulk operations,
 like LIST.
 
-In general, we never modify either of these -- all modifications go in either Spec or Status
+In general, we never modify either of these -- all modifications go in either Spec or Status.
 
 That little `+kubebuilder:object:root` comment is called a marker.  We'll see
 more of them in a bit, but know that they act as extra metadata, telling

docs/book/src/cronjob-tutorial/testdata/emptycontroller.go

@@ -33,7 +33,7 @@ import (
 )
 
 /*
-Next, kubebuilder has scaffold out a basic reconciler struct for us.
+Next, kubebuilder has scaffolded a basic reconciler struct for us.
 Pretty much every reconciler needs to log, and needs to be able to fetch
 objects, so these are added out of the box.
 */

docs/book/src/multiversion-tutorial/api-changes.md

@@ -23,7 +23,7 @@ also need to make sure anything we add in v2 is supported in v2.  In some
 cases, this means we need to add new fields to v1, but in our case, we
 won't have to, since we're not adding new functionality.
 
-Keeping all that in mind, let's figure convert our example above to be
+Keeping all that in mind, let's convert our example above to be
 slightly more structured:
 
 ```yaml