mirror of
				https://github.com/optim-enterprises-bv/kubernetes.git
				synced 2025-11-03 19:58:17 +00:00 
			
		
		
		
	Delete the simple-yaml.md example
This commit is contained in:
		@@ -77,8 +77,8 @@ but with different flags and/or different memory and cpu requests for different
 | 
			
		||||
### Required Fields
 | 
			
		||||
 | 
			
		||||
As with all other Kubernetes config, a DaemonSet needs `apiVersion`, `kind`, and `metadata` fields.  For
 | 
			
		||||
general information about working with config files, see [here](../user-guide/simple-yaml.md),
 | 
			
		||||
[here](../user-guide/configuring-containers.md), and [here](../user-guide/working-with-resources.md).
 | 
			
		||||
general information about working with config files, see [deploying applications](../user-guide/deploying-applications.md),
 | 
			
		||||
[configuring containers](../user-guide/configuring-containers.md), and [working with resources](../user-guide/working-with-resources.md) documents.
 | 
			
		||||
 | 
			
		||||
A DaemonSet also needs a [`.spec`](../devel/api-conventions.md#spec-and-status) section.
 | 
			
		||||
 | 
			
		||||
 
 | 
			
		||||
@@ -114,7 +114,7 @@ A minimal Ingress might look like:
 | 
			
		||||
 | 
			
		||||
*POSTing this to the API server will have no effect if you have not configured an [Ingress controller](#ingress-controllers).*
 | 
			
		||||
 | 
			
		||||
__Lines 1-4__: As with all other Kubernetes config, an Ingress needs `apiVersion`, `kind`, and `metadata` fields.  For general information about working with config files, see [here](simple-yaml.md), [here](configuring-containers.md), and [here](working-with-resources.md).
 | 
			
		||||
__Lines 1-4__: As with all other Kubernetes config, an Ingress needs `apiVersion`, `kind`, and `metadata` fields.  For general information about working with config files, see [deploying applications](deploying-applications.md), [configuring containers](configuring-containers.md), and [working with resources](working-with-resources.md) documents.
 | 
			
		||||
 | 
			
		||||
__Lines 5-7__: Ingress [spec](../devel/api-conventions.md#spec-and-status) has all the information needed to configure a loadbalancer or proxy server. Most importantly, it contains a list of rules matched against all incoming requests. Currently the Ingress resource only supports http rules.
 | 
			
		||||
 | 
			
		||||
 
 | 
			
		||||
@@ -143,8 +143,8 @@ $ kubectl logs pi-aiw0a
 | 
			
		||||
## Writing a Job Spec
 | 
			
		||||
 | 
			
		||||
As with all other Kubernetes config, a Job needs `apiVersion`, `kind`, and `metadata` fields.  For
 | 
			
		||||
general information about working with config files, see [here](simple-yaml.md),
 | 
			
		||||
[here](configuring-containers.md), and [here](working-with-resources.md).
 | 
			
		||||
general information about working with config files, see [deploying applications](deploying-applications.md),
 | 
			
		||||
[configuring containers](configuring-containers.md), and [working with resources](working-with-resources.md) documents.
 | 
			
		||||
 | 
			
		||||
A Job also needs a [`.spec` section](../devel/api-conventions.md#spec-and-status).
 | 
			
		||||
 | 
			
		||||
 
 | 
			
		||||
@@ -117,8 +117,8 @@ It is a recommended practice to put resources related to the same microservice o
 | 
			
		||||
A URL can also be specified as a configuration source, which is handy for deploying directly from configuration files checked into github:
 | 
			
		||||
 | 
			
		||||
```console
 | 
			
		||||
$ kubectl create -f https://raw.githubusercontent.com/GoogleCloudPlatform/kubernetes/master/docs/user-guide/replication.yaml
 | 
			
		||||
replicationcontrollers/nginx
 | 
			
		||||
$ kubectl create -f https://raw.githubusercontent.com/GoogleCloudPlatform/kubernetes/master/docs/user-guide/pod.yaml
 | 
			
		||||
pods/nginx
 | 
			
		||||
```
 | 
			
		||||
 | 
			
		||||
## Bulk operations in kubectl
 | 
			
		||||
 
 | 
			
		||||
@@ -1,19 +0,0 @@
 | 
			
		||||
apiVersion: v1
 | 
			
		||||
kind: ReplicationController
 | 
			
		||||
metadata:
 | 
			
		||||
  name: nginx
 | 
			
		||||
spec:
 | 
			
		||||
  replicas: 3
 | 
			
		||||
  selector:
 | 
			
		||||
    app: nginx
 | 
			
		||||
  template:
 | 
			
		||||
    metadata:
 | 
			
		||||
      name: nginx
 | 
			
		||||
      labels:
 | 
			
		||||
        app: nginx
 | 
			
		||||
    spec:
 | 
			
		||||
      containers:
 | 
			
		||||
      - name: nginx
 | 
			
		||||
        image: nginx
 | 
			
		||||
        ports:
 | 
			
		||||
        - containerPort: 80
 | 
			
		||||
@@ -84,7 +84,7 @@ In order to access your nginx landing page, you also have to make sure that traf
 | 
			
		||||
 | 
			
		||||
### Next: Configuration files
 | 
			
		||||
 | 
			
		||||
Most people will eventually want to use declarative configuration files for creating/modifying their applications.  A [simplified introduction](simple-yaml.md)
 | 
			
		||||
Most people will eventually want to use declarative configuration files for creating/modifying their applications.  A [simplified introduction](deploying-applications.md)
 | 
			
		||||
is given in a different document.
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 
 | 
			
		||||
@@ -31,100 +31,7 @@ Documentation for other releases can be found at
 | 
			
		||||
 | 
			
		||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
 | 
			
		||||
 | 
			
		||||
## Getting started with config files.
 | 
			
		||||
 | 
			
		||||
In addition to the imperative style commands described [elsewhere](simple-nginx.md), Kubernetes
 | 
			
		||||
supports declarative YAML or JSON configuration files.  Often times config files are preferable
 | 
			
		||||
to imperative commands, since they can be checked into version control and changes to the files
 | 
			
		||||
can be code reviewed, producing a more robust, reliable and archival system.
 | 
			
		||||
 | 
			
		||||
### Running a container from a pod configuration file
 | 
			
		||||
 | 
			
		||||
```console
 | 
			
		||||
$ cd kubernetes
 | 
			
		||||
$ kubectl create -f ./pod.yaml
 | 
			
		||||
```
 | 
			
		||||
 | 
			
		||||
Where pod.yaml contains something like:
 | 
			
		||||
 | 
			
		||||
<!-- BEGIN MUNGE: EXAMPLE pod.yaml -->
 | 
			
		||||
 | 
			
		||||
```yaml
 | 
			
		||||
apiVersion: v1
 | 
			
		||||
kind: Pod
 | 
			
		||||
metadata:
 | 
			
		||||
  name: nginx
 | 
			
		||||
  labels:
 | 
			
		||||
    app: nginx
 | 
			
		||||
spec:
 | 
			
		||||
  containers:
 | 
			
		||||
  - name: nginx
 | 
			
		||||
    image: nginx
 | 
			
		||||
    ports:
 | 
			
		||||
    - containerPort: 80
 | 
			
		||||
```
 | 
			
		||||
 | 
			
		||||
[Download example](pod.yaml?raw=true)
 | 
			
		||||
<!-- END MUNGE: EXAMPLE pod.yaml -->
 | 
			
		||||
 | 
			
		||||
You can see your cluster's pods:
 | 
			
		||||
 | 
			
		||||
```console
 | 
			
		||||
$ kubectl get pods
 | 
			
		||||
```
 | 
			
		||||
 | 
			
		||||
and delete the pod you just created:
 | 
			
		||||
 | 
			
		||||
```console
 | 
			
		||||
$ kubectl delete pods nginx
 | 
			
		||||
```
 | 
			
		||||
 | 
			
		||||
### Running a replicated set of containers from a configuration file
 | 
			
		||||
 | 
			
		||||
To run replicated containers, you need a [Replication Controller](replication-controller.md).
 | 
			
		||||
A replication controller is responsible for ensuring that a specific number of pods exist in the
 | 
			
		||||
cluster.
 | 
			
		||||
 | 
			
		||||
```console
 | 
			
		||||
$ cd kubernetes
 | 
			
		||||
$ kubectl create -f ./replication.yaml
 | 
			
		||||
```
 | 
			
		||||
 | 
			
		||||
Where `replication.yaml` contains:
 | 
			
		||||
 | 
			
		||||
<!-- BEGIN MUNGE: EXAMPLE replication.yaml -->
 | 
			
		||||
 | 
			
		||||
```yaml
 | 
			
		||||
apiVersion: v1
 | 
			
		||||
kind: ReplicationController
 | 
			
		||||
metadata:
 | 
			
		||||
  name: nginx
 | 
			
		||||
spec:
 | 
			
		||||
  replicas: 3
 | 
			
		||||
  selector:
 | 
			
		||||
    app: nginx
 | 
			
		||||
  template:
 | 
			
		||||
    metadata:
 | 
			
		||||
      name: nginx
 | 
			
		||||
      labels:
 | 
			
		||||
        app: nginx
 | 
			
		||||
    spec:
 | 
			
		||||
      containers:
 | 
			
		||||
      - name: nginx
 | 
			
		||||
        image: nginx
 | 
			
		||||
        ports:
 | 
			
		||||
        - containerPort: 80
 | 
			
		||||
```
 | 
			
		||||
 | 
			
		||||
[Download example](replication.yaml?raw=true)
 | 
			
		||||
<!-- END MUNGE: EXAMPLE replication.yaml -->
 | 
			
		||||
 | 
			
		||||
To delete the replication controller (and the pods it created):
 | 
			
		||||
 | 
			
		||||
```console
 | 
			
		||||
$ kubectl delete rc nginx
 | 
			
		||||
```
 | 
			
		||||
 | 
			
		||||
### This document has been subsumed by [deploying-applications.md](deploying-applications.md)
 | 
			
		||||
 | 
			
		||||
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
 | 
			
		||||
[]()
 | 
			
		||||
 
 | 
			
		||||
@@ -225,7 +225,6 @@ func TestExampleObjectSchemas(t *testing.T) {
 | 
			
		||||
		"../docs/user-guide": {
 | 
			
		||||
			"multi-pod":            nil,
 | 
			
		||||
			"pod":                  &api.Pod{},
 | 
			
		||||
			"replication":          &api.ReplicationController{},
 | 
			
		||||
			"job":                  &extensions.Job{},
 | 
			
		||||
			"ingress":              &extensions.Ingress{},
 | 
			
		||||
			"nginx-deployment":     &extensions.Deployment{},
 | 
			
		||||
@@ -464,7 +463,6 @@ func TestReadme(t *testing.T) {
 | 
			
		||||
		{"../README.md", []runtime.Object{&api.Pod{}}},
 | 
			
		||||
		{"../docs/user-guide/walkthrough/README.md", []runtime.Object{&api.Pod{}}},
 | 
			
		||||
		{"../examples/iscsi/README.md", []runtime.Object{&api.Pod{}}},
 | 
			
		||||
		{"../docs/user-guide/simple-yaml.md", []runtime.Object{&api.Pod{}, &api.ReplicationController{}}},
 | 
			
		||||
	}
 | 
			
		||||
 | 
			
		||||
	for _, path := range paths {
 | 
			
		||||
 
 | 
			
		||||
@@ -84,7 +84,7 @@ In order to access your nginx landing page, you also have to make sure that traf
 | 
			
		||||
 | 
			
		||||
### Next: Configuration files
 | 
			
		||||
 | 
			
		||||
Most people will eventually want to use declarative configuration files for creating/modifying their applications.  A [simplified introduction](../docs/user-guide/simple-yaml.md)
 | 
			
		||||
Most people will eventually want to use declarative configuration files for creating/modifying their applications.  A [simplified introduction](../docs/user-guide/deploying-applications.md)
 | 
			
		||||
is given in a different document.
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 
 | 
			
		||||
		Reference in New Issue
	
	Block a user