symbol errors in quotation mark
Signed-off-by: tim-zju <21651152@zju.edu.cn>
This commit is contained in:
@@ -328,7 +328,7 @@ Host: k8s-master:8080
|
||||
```
|
||||
|
||||
To consume opaque resources in pods, include the name of the opaque
|
||||
resource as a key in the the `spec.containers[].resources.requests` map.
|
||||
resource as a key in the `spec.containers[].resources.requests` map.
|
||||
|
||||
The pod will be scheduled only if all of the resource requests are
|
||||
satisfied (including cpu, memory and any opaque resources.) The pod will
|
||||
|
||||
@@ -20,7 +20,9 @@ or used to store configuration data for system components such as controllers.
|
||||
to [Secrets](/docs/user-guide/secrets/), but designed to more conveniently support working with strings that do not
|
||||
contain sensitive information.
|
||||
|
||||
Let's look at a made-up example:
|
||||
Note: ConfigMaps are not intended to act as a replacement for a properties file. ConfigMaps are intended to act as a reference to multiple properties files. You can think of them as way to represent something similar to the /etc directory, and the files within, on a Linux computer. One example of this model is creating Kubernetes Volumes from ConfigMaps, where each data item in the ConfigMap becomes a new file.
|
||||
|
||||
Consider the following example:
|
||||
|
||||
```yaml
|
||||
kind: ConfigMap
|
||||
|
||||
@@ -90,7 +90,7 @@ The cluster has to be started with `ENABLE_CUSTOM_METRICS` environment variable
|
||||
### Pod configuration
|
||||
|
||||
The pods to be scaled must have cAdvisor-specific custom (aka application) metrics endpoint configured. The configuration format is described [here](https://github.com/google/cadvisor/blob/master/docs/application_metrics.md). Kubernetes expects the configuration to
|
||||
be placed in `definition.json` mounted via a [config map](/docs/user-guide/horizontal-pod-autoscaling/configmap/) in `/etc/custom-metrics`. A sample config map may look like this:
|
||||
be placed in `definition.json` mounted via a [config map](/docs/user-guide/configmap/) in `/etc/custom-metrics`. A sample config map may look like this:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
|
||||
@@ -69,7 +69,7 @@ kubectl get [(-o|--output=)json|yaml|wide|custom-columns=...|custom-columns-file
|
||||
kubectl get -f pod.yaml -o json
|
||||
|
||||
# Return only the phase value of the specified pod.
|
||||
kubectl get -o template pod/web-pod-13je7 --template={% raw %}{{.status.phase}}{% endraw %}
|
||||
kubectl get -o template pod/web-pod-13je7 --template={{.status.phase}}
|
||||
|
||||
# List all replication controllers and services together in ps output format.
|
||||
kubectl get rc,services
|
||||
|
||||
@@ -70,7 +70,36 @@ When a user is done with their volume, they can delete the PVC objects from the
|
||||
|
||||
### Reclaiming
|
||||
|
||||
The reclaim policy for a `PersistentVolume` tells the cluster what to do with the volume after it has been released of its claim. Currently, volumes can either be Retained, Recycled or Deleted. Retention allows for manual reclamation of the resource. For those volume plugins that support it, deletion removes both the `PersistentVolume` object from Kubernetes as well as deletes associated storage asset in external infrastructure such as AWS EBS, GCE PD or Cinder volume. Volumes that were dynamically provisioned are always deleted. If supported by appropriate volume plugin, recycling performs a basic scrub (`rm -rf /thevolume/*`) on the volume and makes it available again for a new claim.
|
||||
The reclaim policy for a `PersistentVolume` tells the cluster what to do with the volume after it has been released of its claim. Currently, volumes can either be Retained, Recycled or Deleted. Retention allows for manual reclamation of the resource. For those volume plugins that support it, deletion removes both the `PersistentVolume` object from Kubernetes as well as deletes associated storage asset in external infrastructure such as AWS EBS, GCE PD or Cinder volume. Volumes that were dynamically provisioned are always deleted.
|
||||
|
||||
#### Recycling
|
||||
|
||||
If supported by appropriate volume plugin, recycling performs a basic scrub (`rm -rf /thevolume/*`) on the volume and makes it available again for a new claim.
|
||||
|
||||
However, an administrator can configure a custom recycler pod templates using the Kubernetes controller manager command line arguments as described [here](/docs/admin/kube-controller-manager/). The custom recycler pod template must contain a `volumes` specification, as shown in the example below:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: pv-recycler-
|
||||
namespace: default
|
||||
spec:
|
||||
restartPolicy: Never
|
||||
volumes:
|
||||
- name: vol
|
||||
hostPath:
|
||||
path: /any/path/it/will/be/replaced
|
||||
containers:
|
||||
- name: pv-recycler
|
||||
image: "gcr.io/google_containers/busybox"
|
||||
command: ["/bin/sh", "-c", "test -e /scrub && rm -rf /scrub/..?* /scrub/.[!.]* /scrub/* && test -z \"$(ls -A /scrub)\" || exit 1"]
|
||||
volumeMounts:
|
||||
- name: vol
|
||||
mountPath: /scrub
|
||||
```
|
||||
|
||||
However, the particular path specified in the custom recycler pod template in the `volumes` part is replaced with the particular path of the volume that is being recycled.
|
||||
|
||||
## Types of Persistent Volumes
|
||||
|
||||
|
||||
@@ -28,6 +28,7 @@ To expose your service to the public internet, run:
|
||||
$ kubectl expose deployment my-nginx --target-port=80 --type=LoadBalancer
|
||||
service "my-nginx" exposed
|
||||
```
|
||||
Note: The type, LoadBalancer, is highly dependent upon the underlying platform that Kubernetes is running on. If your cloud provider doesn't have a load balancer implementation (e.g. OpenStack) for Kubernetes, you can simply use the allocated [NodePort](http://kubernetes.io/docs/user-guide/services/#type-nodeport) as a rudimentary form of load balancing across your endpoints.
|
||||
|
||||
You can see that they are running by:
|
||||
|
||||
|
||||
@@ -158,7 +158,7 @@ type: Opaque
|
||||
Decode the password field:
|
||||
|
||||
```shell
|
||||
$ echo "MWYyZDFlMmU2N2Rm" | base64 -d
|
||||
$ echo "MWYyZDFlMmU2N2Rm" | base64 --decode
|
||||
1f2d1e2e67df
|
||||
```
|
||||
|
||||
|
||||
Reference in New Issue
Block a user