github
/
k3s
mirror of https://github.com/k3s-io/k3s
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

docs: make markdown less GitHub-specific 

- add newline before lists
- use ‘*’ for lists instead of ‘-’; use 4 spaces to indent nested list
pull/6/head
Thien-Thi Nguyen 2015-06-17 17:59:05 +02:00
parent d8e5225144
commit 1647e12c4e
2 changed files with 19 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
docs/api.md
View File

@ -37,11 +37,13 @@ As of June 4, 2015, the Kubernetes v1 API has been enabled by default. The v1bet
We're working to convert all documentation and examples to v1. A simple [API conversion tool](cluster_management.md#switching-your-config-files-to-a-new-api-version) has been written to simplify the translation process. Use `kubectl create --validate` in order to validate your json or yaml against our Swagger spec.
Changes to services are the most significant difference between v1beta3 and v1.
* The `service.spec.portalIP` property is renamed to `service.spec.clusterIP`.
* The `service.spec.createExternalLoadBalancer` property is removed. Specify `service.spec.type: "LoadBalancer"` to create an external load balancer instead.
* The `service.spec.publicIPs` property is deprecated and now called `service.spec.deprecatedPublicIPs`. This property will be removed entirely when v1beta3 is removed. The vast majority of users of this field were using it to expose services on ports on the node. Those users should specify `service.spec.type: "NodePort"` instead. Read [External Services](services.md#external-services) for more info. If this is not sufficient for your use case, please file an issue or contact @thockin.
Some other difference between v1beta3 and v1:
* The `pod.spec.containers[*].privileged` and `pod.spec.containers[*].capabilities` properties are now nested under the `pod.spec.containers[*].securityContext` property. See [Security Contexts](security_context.md).
* The `pod.spec.host` property is renamed to `pod.spec.nodeName`.
* The `endpoints.subsets[*].addresses.IP` property is renamed to `endpoints.subsets[*].addresses.ip`.
@ -52,6 +54,7 @@ Some other difference between v1beta3 and v1:
### v1beta3 conversion tips (from v1beta1/2)
Some important differences between v1beta1/2 and v1beta3:
* The resource `id` is now called `name`.
* `name`, `labels`, `annotations`, and other metadata are now nested in a map called `metadata`
* `desiredState` is now called `spec`, and `currentState` is now called `status`

28
docs/volumes.md
View File

@ -20,8 +20,9 @@ Selected volume types are described below.
An EmptyDir volume is created when a Pod is bound to a Node. It is initially empty, when the first Container command starts. Containers in the same pod can all read and write the same files in the EmptyDir volume. When a Pod is unbound, the data in the EmptyDir is deleted forever.
Some uses for an EmptyDir are:
- scratch space, such as for a disk-based mergesort or checkpointing a long computation,
- a directory that a content-manager container fills with data while a webserver container serves the data.
* scratch space, such as for a disk-based mergesort or checkpointing a long computation,
* a directory that a content-manager container fills with data while a webserver container serves the data.
Currently, the user cannot control what kind of media is used for an EmptyDir (see also the section _Resources_, below). If the Kubelet is configured to use a disk drive, then all EmptyDir volumes will be created on that disk drive. In the future, it is expected that Pods can control whether the EmptyDir is on a disk drive, SSD, or tmpfs.
@ -29,12 +30,14 @@ Currently, the user cannot control what kind of media is used for an EmptyDir (s
A Volume with a HostPath property allows access to files on the current node.
Some uses for a HostPath are:
- running a container that needs access to Docker internals; use a HostPath of /var/lib/docker.
- running cAdvisor in a container; use a HostPath of /dev/cgroups.
* running a container that needs access to Docker internals; use a HostPath of /var/lib/docker.
* running cAdvisor in a container; use a HostPath of /dev/cgroups.
Watch out when using this type of volume, because:
- pods with identical configuration (such as created from a podTemplate) may behave differently on different nodes due to different files on different nodes.
- When Kubernetes adds resource-aware scheduling, as is planned, it will not be able to account for resources used by a HostPath.
* pods with identical configuration (such as created from a podTemplate) may behave differently on different nodes due to different files on different nodes.
* When Kubernetes adds resource-aware scheduling, as is planned, it will not be able to account for resources used by a HostPath.
### GCEPersistentDisk
__Important: You must create a PD using ```gcloud``` or the GCE API before you can use it__
@ -43,12 +46,13 @@ A Volume with a GCEPersistentDisk property allows access to files on a Google Co
[Persistent Disk](http://cloud.google.com/compute/docs/disks).
There are some restrictions when using a GCEPersistentDisk:
- the nodes (what the kubelet runs on) need to be GCE VMs
- those VMs need to be in the same GCE project and zone as the PD
- avoid creating multiple pods that use the same Volume if any mount it read/write.
- if a pod P already mounts a volume read/write, and a second pod Q attempts to use the volume, regardless of if it tries to use it read-only or read/write, Q will fail.
- if a pod P already mounts a volume read-only, and a second pod Q attempts to use the volume read/write, Q will fail.
- replication controllers with replicas > 1 can only be created for pods that use read-only mounts.
* the nodes (what the kubelet runs on) need to be GCE VMs
* those VMs need to be in the same GCE project and zone as the PD
* avoid creating multiple pods that use the same Volume if any mount it read/write.
* if a pod P already mounts a volume read/write, and a second pod Q attempts to use the volume, regardless of if it tries to use it read-only or read/write, Q will fail.
* if a pod P already mounts a volume read-only, and a second pod Q attempts to use the volume read/write, Q will fail.
* replication controllers with replicas > 1 can only be created for pods that use read-only mounts.
#### Creating a PD
Before you can use a GCE PD with a pod, you need to create it.