Consolidate YAML files [part-12] (#9364)
* Consolidate YAML files [part-12] Relocate YAML files referenced by the accessing application topic and the rest of cluster administration. * Adjust json shortcodes.
This commit is contained in:
Qiming
+2
-2
@@ -27,7 +27,7 @@ In this exercise, you create a Pod that runs two Containers. The two containers
|
||||
share a Volume that they can use to communicate. Here is the configuration file
|
||||
for the Pod:
|
||||
|
||||
{{< code file="two-container-pod.yaml" >}}
|
||||
{{< codenew file="pods/two-container-pod.yaml" >}}
|
||||
|
||||
In the configuration file, you can see that the Pod has a Volume named
|
||||
`shared-data`.
|
||||
@@ -44,7 +44,7 @@ directory of the nginx server.
|
||||
|
||||
Create the Pod and the two Containers:
|
||||
|
||||
kubectl create -f https://k8s.io/docs/tasks/access-application-cluster/two-container-pod.yaml
|
||||
kubectl create -f https://k8s.io/examples/pods/two-container-pod.yaml
|
||||
|
||||
View information about the Pod and the Containers:
|
||||
|
||||
|
||||
@@ -43,12 +43,12 @@ frontend and backend are connected using a Kubernetes Service object.
|
||||
The backend is a simple hello greeter microservice. Here is the configuration
|
||||
file for the backend Deployment:
|
||||
|
||||
{{< code file="hello.yaml" >}}
|
||||
{{< codenew file="service/access/hello.yaml" >}}
|
||||
|
||||
Create the backend Deployment:
|
||||
|
||||
```
|
||||
kubectl create -f https://k8s.io/docs/tasks/access-application-cluster/hello.yaml
|
||||
kubectl create -f https://k8s.io/examples/service/access/hello.yaml
|
||||
```
|
||||
|
||||
View information about the backend Deployment:
|
||||
@@ -103,7 +103,7 @@ selector labels to find the Pods that it routes traffic to.
|
||||
|
||||
First, explore the Service configuration file:
|
||||
|
||||
{{< code file="hello-service.yaml" >}}
|
||||
{{< codenew file="service/access/hello-service.yaml" >}}
|
||||
|
||||
In the configuration file, you can see that the Service routes traffic to Pods
|
||||
that have the labels `app: hello` and `tier: backend`.
|
||||
@@ -111,7 +111,7 @@ that have the labels `app: hello` and `tier: backend`.
|
||||
Create the `hello` Service:
|
||||
|
||||
```
|
||||
kubectl create -f https://k8s.io/docs/tasks/access-application-cluster/hello-service.yaml
|
||||
kubectl create -f https://k8s.io/examples/service/access/hello-service.yaml
|
||||
```
|
||||
|
||||
At this point, you have a backend Deployment running, and you have a
|
||||
@@ -127,18 +127,18 @@ of the `name` field in the preceding Service configuration file.
|
||||
The Pods in the frontend Deployment run an nginx image that is configured
|
||||
to find the hello backend Service. Here is the nginx configuration file:
|
||||
|
||||
{{< code file="frontend/frontend.conf" >}}
|
||||
{{< codenew file="service/access/frontend.conf" >}}
|
||||
|
||||
Similar to the backend, the frontend has a Deployment and a Service. The
|
||||
configuration for the Service has `type: LoadBalancer`, which means that
|
||||
the Service uses the default load balancer of your cloud provider.
|
||||
|
||||
{{< code file="frontend.yaml" >}}
|
||||
{{< codenew file="service/access/frontend.yaml" >}}
|
||||
|
||||
Create the frontend Deployment and Service:
|
||||
|
||||
```
|
||||
kubectl create -f https://k8s.io/docs/tasks/access-application-cluster/frontend.yaml
|
||||
kubectl create -f https://k8s.io/examples/service/access/frontend.yaml
|
||||
```
|
||||
|
||||
The output verifies that both resources were created:
|
||||
@@ -149,7 +149,7 @@ service "frontend" created
|
||||
```
|
||||
|
||||
**Note**: The nginx configuration is baked into the
|
||||
[container image](/docs/tasks/access-application-cluster/frontend/Dockerfile).
|
||||
[container image](/examples/service/access/Dockerfile).
|
||||
A better way to do this would be to use a
|
||||
[ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/), so
|
||||
that you can change the configuration more easily.
|
||||
|
||||
@@ -1,39 +0,0 @@
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: frontend
|
||||
spec:
|
||||
selector:
|
||||
app: hello
|
||||
tier: frontend
|
||||
ports:
|
||||
- protocol: "TCP"
|
||||
port: 80
|
||||
targetPort: 80
|
||||
type: LoadBalancer
|
||||
---
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: frontend
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
app: hello
|
||||
tier: frontend
|
||||
track: stable
|
||||
replicas: 1
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: hello
|
||||
tier: frontend
|
||||
track: stable
|
||||
spec:
|
||||
containers:
|
||||
- name: nginx
|
||||
image: "gcr.io/google-samples/hello-frontend:1.0"
|
||||
lifecycle:
|
||||
preStop:
|
||||
exec:
|
||||
command: ["/usr/sbin/nginx","-s","quit"]
|
||||
@@ -1,4 +0,0 @@
|
||||
FROM nginx:1.9.14
|
||||
|
||||
RUN rm /etc/nginx/conf.d/default.conf
|
||||
COPY frontend.conf /etc/nginx/conf.d
|
||||
@@ -1,11 +0,0 @@
|
||||
upstream hello {
|
||||
server hello;
|
||||
}
|
||||
|
||||
server {
|
||||
listen 80;
|
||||
|
||||
location / {
|
||||
proxy_pass http://hello;
|
||||
}
|
||||
}
|
||||
@@ -1,12 +0,0 @@
|
||||
kind: Service
|
||||
apiVersion: v1
|
||||
metadata:
|
||||
name: hello
|
||||
spec:
|
||||
selector:
|
||||
app: hello
|
||||
tier: backend
|
||||
ports:
|
||||
- protocol: TCP
|
||||
port: 80
|
||||
targetPort: http
|
||||
@@ -1,24 +0,0 @@
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: hello
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
app: hello
|
||||
tier: backend
|
||||
track: stable
|
||||
replicas: 7
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: hello
|
||||
tier: backend
|
||||
track: stable
|
||||
spec:
|
||||
containers:
|
||||
- name: hello
|
||||
image: "gcr.io/google-samples/hello-go-gke:1.0"
|
||||
ports:
|
||||
- name: http
|
||||
containerPort: 80
|
||||
@@ -1,4 +0,0 @@
|
||||
FROM alpine:3.1
|
||||
MAINTAINER Carter Morgan <askcarter@google.com>
|
||||
COPY hello /usr/bin/
|
||||
CMD ["/usr/bin/hello"]
|
||||
@@ -1,7 +0,0 @@
|
||||
Build hello go binary first
|
||||
|
||||
go build -tags netgo -ldflags "-extldflags '-lm -lstdc++ -static'" .
|
||||
|
||||
Then build docker image
|
||||
|
||||
docker build -t hello .
|
||||
@@ -1,74 +0,0 @@
|
||||
package main
|
||||
|
||||
import (
|
||||
"flag"
|
||||
"fmt"
|
||||
"log"
|
||||
"net/http"
|
||||
"os"
|
||||
"os/signal"
|
||||
"syscall"
|
||||
|
||||
"github.com/braintree/manners"
|
||||
"github.com/GoogleCloudPlatform/kubernetes-workshops/bundles/kubernetes-101/workshop/app/handlers"
|
||||
"github.com/GoogleCloudPlatform/kubernetes-workshops/bundles/kubernetes-101/workshop/app/health"
|
||||
)
|
||||
|
||||
const version = "1.0.0"
|
||||
|
||||
func main() {
|
||||
var (
|
||||
httpAddr = flag.String("http", "0.0.0.0:80", "HTTP service address.")
|
||||
healthAddr = flag.String("health", "0.0.0.0:81", "Health service address.")
|
||||
)
|
||||
flag.Parse()
|
||||
|
||||
log.Println("Starting server...")
|
||||
log.Printf("Health service listening on %s", *healthAddr)
|
||||
log.Printf("HTTP service listening on %s", *httpAddr)
|
||||
|
||||
errChan := make(chan error, 10)
|
||||
|
||||
hmux := http.NewServeMux()
|
||||
hmux.HandleFunc("/healthz", health.HealthzHandler)
|
||||
hmux.HandleFunc("/readiness", health.ReadinessHandler)
|
||||
hmux.HandleFunc("/healthz/status", health.HealthzStatusHandler)
|
||||
hmux.HandleFunc("/readiness/status", health.ReadinessStatusHandler)
|
||||
healthServer := manners.NewServer()
|
||||
healthServer.Addr = *healthAddr
|
||||
healthServer.Handler = handlers.LoggingHandler(hmux)
|
||||
|
||||
go func() {
|
||||
errChan <- healthServer.ListenAndServe()
|
||||
}()
|
||||
|
||||
mux := http.NewServeMux()
|
||||
mux.HandleFunc("/", handlers.HelloHandler)
|
||||
mux.Handle("/secure", handlers.JWTAuthHandler(handlers.HelloHandler))
|
||||
mux.Handle("/version", handlers.VersionHandler(version))
|
||||
|
||||
httpServer := manners.NewServer()
|
||||
httpServer.Addr = *httpAddr
|
||||
httpServer.Handler = handlers.LoggingHandler(mux)
|
||||
|
||||
go func() {
|
||||
errChan <- httpServer.ListenAndServe()
|
||||
}()
|
||||
|
||||
signalChan := make(chan os.Signal, 1)
|
||||
signal.Notify(signalChan, syscall.SIGINT, syscall.SIGTERM)
|
||||
|
||||
for {
|
||||
select {
|
||||
case err := <-errChan:
|
||||
if err != nil {
|
||||
log.Fatal(err)
|
||||
}
|
||||
case s := <-signalChan:
|
||||
log.Println(fmt.Sprintf("Captured %v. Exiting...", s))
|
||||
health.SetReadinessStatus(http.StatusServiceUnavailable)
|
||||
httpServer.BlockingClose()
|
||||
os.Exit(0)
|
||||
}
|
||||
}
|
||||
}
|
||||
@@ -1,33 +0,0 @@
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
labels:
|
||||
name: redis
|
||||
redis-sentinel: "true"
|
||||
role: master
|
||||
name: redis-master
|
||||
spec:
|
||||
containers:
|
||||
- name: master
|
||||
image: k8s.gcr.io/redis:v1
|
||||
env:
|
||||
- name: MASTER
|
||||
value: "true"
|
||||
ports:
|
||||
- containerPort: 6379
|
||||
resources:
|
||||
limits:
|
||||
cpu: "0.1"
|
||||
volumeMounts:
|
||||
- mountPath: /redis-master-data
|
||||
name: data
|
||||
- name: sentinel
|
||||
image: kubernetes/redis:v1
|
||||
env:
|
||||
- name: SENTINEL
|
||||
value: "true"
|
||||
ports:
|
||||
- containerPort: 26379
|
||||
volumes:
|
||||
- name: data
|
||||
emptyDir: {}
|
||||
@@ -1,27 +0,0 @@
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: two-containers
|
||||
spec:
|
||||
|
||||
restartPolicy: Never
|
||||
|
||||
volumes:
|
||||
- name: shared-data
|
||||
emptyDir: {}
|
||||
|
||||
containers:
|
||||
|
||||
- name: nginx-container
|
||||
image: nginx
|
||||
volumeMounts:
|
||||
- name: shared-data
|
||||
mountPath: /usr/share/nginx/html
|
||||
|
||||
- name: debian-container
|
||||
image: debian
|
||||
volumeMounts:
|
||||
- name: shared-data
|
||||
mountPath: /pod-data
|
||||
command: ["/bin/sh"]
|
||||
args: ["-c", "echo Hello from the debian container > /pod-data/index.html"]
|
||||
@@ -1,14 +0,0 @@
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: busybox
|
||||
namespace: default
|
||||
spec:
|
||||
containers:
|
||||
- name: busybox
|
||||
image: busybox
|
||||
command:
|
||||
- sleep
|
||||
- "3600"
|
||||
imagePullPolicy: IfNotPresent
|
||||
restartPolicy: Always
|
||||
-69
@@ -1,69 +0,0 @@
|
||||
# This is an example of how to setup cloud-controller-manger as a Daemonset in your cluster.
|
||||
# It assumes that your masters can run pods and has the role node-role.kubernetes.io/master
|
||||
# Note that this Daemonset will not work straight out of the box for your cloud, this is
|
||||
# meant to be a guideline.
|
||||
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: ServiceAccount
|
||||
metadata:
|
||||
name: cloud-controller-manager
|
||||
namespace: kube-system
|
||||
---
|
||||
kind: ClusterRoleBinding
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
metadata:
|
||||
name: system:cloud-controller-manager
|
||||
roleRef:
|
||||
apiGroup: rbac.authorization.k8s.io
|
||||
kind: ClusterRole
|
||||
name: cluster-admin
|
||||
subjects:
|
||||
- kind: ServiceAccount
|
||||
name: cloud-controller-manager
|
||||
namespace: kube-system
|
||||
---
|
||||
apiVersion: apps/v1
|
||||
kind: DaemonSet
|
||||
metadata:
|
||||
labels:
|
||||
k8s-app: cloud-controller-manager
|
||||
name: cloud-controller-manager
|
||||
namespace: kube-system
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
k8s-app: cloud-controller-manager
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
k8s-app: cloud-controller-manager
|
||||
spec:
|
||||
serviceAccountName: cloud-controller-manager
|
||||
containers:
|
||||
- name: cloud-controller-manager
|
||||
# for in-tree providers we use k8s.gcr.io/cloud-controller-manager
|
||||
# this can be replaced with any other image for out-of-tree providers
|
||||
image: k8s.gcr.io/cloud-controller-manager:v1.8.0
|
||||
command:
|
||||
- /usr/local/bin/cloud-controller-manager
|
||||
- --cloud-provider=<YOUR_CLOUD_PROVIDER> # Add your own cloud provider here!
|
||||
- --leader-elect=true
|
||||
- --use-service-account-credentials
|
||||
# these flags will vary for every cloud provider
|
||||
- --allocate-node-cidrs=true
|
||||
- --configure-cloud-routes=true
|
||||
- --cluster-cidr=172.17.0.0/16
|
||||
tolerations:
|
||||
# this is required so CCM can bootstrap itself
|
||||
- key: node.cloudprovider.kubernetes.io/uninitialized
|
||||
value: "true"
|
||||
effect: NoSchedule
|
||||
# this is to have the daemonset runnable on master nodes
|
||||
# the taint may vary depending on your cluster setup
|
||||
- key: node-role.kubernetes.io/master
|
||||
effect: NoSchedule
|
||||
# this is to restrict CCM to only run on master nodes
|
||||
# the node selector may vary depending on your cluster setup
|
||||
nodeSelector:
|
||||
node-role.kubernetes.io/master: ""
|
||||
@@ -73,7 +73,7 @@ for this example. A [Deployment](/docs/concepts/workloads/controllers/deployment
|
||||
thereby making the scheduler resilient to failures. Here is the deployment
|
||||
config. Save it as `my-scheduler.yaml`:
|
||||
|
||||
{{< code file="my-scheduler.yaml" >}}
|
||||
{{< codenew file="admin/sched/my-scheduler.yaml" >}}
|
||||
|
||||
An important thing to note here is that the name of the scheduler specified as an
|
||||
argument to the scheduler command in the container spec should be unique. This is the name that is matched against the value of the optional `spec.schedulerName` on pods, to determine whether this scheduler is responsible for scheduling a particular pod.
|
||||
@@ -149,7 +149,7 @@ scheduler in that pod spec. Let's look at three examples.
|
||||
|
||||
- Pod spec without any scheduler name
|
||||
|
||||
{{< code file="pod1.yaml" >}}
|
||||
{{< codenew file="admin/sched/pod1.yaml" >}}
|
||||
|
||||
When no scheduler name is supplied, the pod is automatically scheduled using the
|
||||
default-scheduler.
|
||||
@@ -162,7 +162,7 @@ kubectl create -f pod1.yaml
|
||||
|
||||
- Pod spec with `default-scheduler`
|
||||
|
||||
{{< code file="pod2.yaml" >}}
|
||||
{{< codenew file="admin/sched/pod2.yaml" >}}
|
||||
|
||||
A scheduler is specified by supplying the scheduler name as a value to `spec.schedulerName`. In this case, we supply the name of the
|
||||
default scheduler which is `default-scheduler`.
|
||||
@@ -175,7 +175,7 @@ kubectl create -f pod2.yaml
|
||||
|
||||
- Pod spec with `my-scheduler`
|
||||
|
||||
{{< code file="pod3.yaml" >}}
|
||||
{{< codenew file="admin/sched/pod3.yaml" >}}
|
||||
|
||||
In this case, we specify that this pod should be scheduled using the scheduler that we
|
||||
deployed - `my-scheduler`. Note that the value of `spec.schedulerName` should match the name supplied to the scheduler
|
||||
@@ -215,4 +215,4 @@ verify that the pods were scheduled by the desired schedulers.
|
||||
kubectl get events
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -22,12 +22,12 @@ This page provides hints on diagnosing DNS problems.
|
||||
|
||||
Create a file named busybox.yaml with the following contents:
|
||||
|
||||
{{< code file="busybox.yaml" >}}
|
||||
{{< codenew file="admin/dns/busybox.yaml" >}}
|
||||
|
||||
Then create a pod using this file and verify its status:
|
||||
|
||||
```shell
|
||||
$ kubectl create -f busybox.yaml
|
||||
$ kubectl create -f https://k8s.io/examples/admin/dns/busybox.yaml
|
||||
pod "busybox" created
|
||||
|
||||
$ kubectl get pods busybox
|
||||
|
||||
@@ -1,33 +0,0 @@
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: kube-dns-autoscaler
|
||||
namespace: kube-system
|
||||
labels:
|
||||
k8s-app: kube-dns-autoscaler
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
k8s-app: kube-dns-autoscaler
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
k8s-app: kube-dns-autoscaler
|
||||
spec:
|
||||
containers:
|
||||
- name: autoscaler
|
||||
image: k8s.gcr.io/cluster-proportional-autoscaler-amd64:1.1.1
|
||||
resources:
|
||||
requests:
|
||||
cpu: "20m"
|
||||
memory: "10Mi"
|
||||
command:
|
||||
- /cluster-proportional-autoscaler
|
||||
- --namespace=kube-system
|
||||
- --configmap=kube-dns-autoscaler
|
||||
- --target=<SCALE_TARGET>
|
||||
# When cluster is using large nodes(with more cores), "coresPerReplica" should dominate.
|
||||
# If using small nodes, "nodesPerReplica" should dominate.
|
||||
- --default-params={"linear":{"coresPerReplica":256,"nodesPerReplica":16,"min":1}}
|
||||
- --logtostderr=true
|
||||
- --v=2
|
||||
@@ -94,7 +94,7 @@ container based on the `cluster-proportional-autoscaler-amd64` image.
|
||||
|
||||
Create a file named `dns-horizontal-autoscaler.yaml` with this content:
|
||||
|
||||
{{< code file="dns-horizontal-autoscaler.yaml" >}}
|
||||
{{< codenew file="admin/dns/dns-horizontal-autoscaler.yaml" >}}
|
||||
|
||||
In the file, replace `<SCALE_TARGET>` with your scale target.
|
||||
|
||||
|
||||
@@ -1,67 +0,0 @@
|
||||
apiVersion: v1
|
||||
kind: ServiceAccount
|
||||
metadata:
|
||||
name: my-scheduler
|
||||
namespace: kube-system
|
||||
---
|
||||
kind: ClusterRoleBinding
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
metadata:
|
||||
name: my-scheduler-as-kube-scheduler
|
||||
subjects:
|
||||
- kind: ServiceAccount
|
||||
name: my-scheduler
|
||||
namespace: kube-system
|
||||
roleRef:
|
||||
kind: ClusterRole
|
||||
name: kube-scheduler
|
||||
apiGroup: rbac.authorization.k8s.io
|
||||
---
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
labels:
|
||||
component: scheduler
|
||||
tier: control-plane
|
||||
name: my-scheduler
|
||||
namespace: kube-system
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
component: scheduler
|
||||
tier: control-plane
|
||||
replicas: 1
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
component: scheduler
|
||||
tier: control-plane
|
||||
version: second
|
||||
spec:
|
||||
serviceAccountName: my-scheduler
|
||||
containers:
|
||||
- command:
|
||||
- /usr/local/bin/kube-scheduler
|
||||
- --address=0.0.0.0
|
||||
- --leader-elect=false
|
||||
- --scheduler-name=my-scheduler
|
||||
image: gcr.io/my-gcp-project/my-kube-scheduler:1.0
|
||||
livenessProbe:
|
||||
httpGet:
|
||||
path: /healthz
|
||||
port: 10251
|
||||
initialDelaySeconds: 15
|
||||
name: kube-second-scheduler
|
||||
readinessProbe:
|
||||
httpGet:
|
||||
path: /healthz
|
||||
port: 10251
|
||||
resources:
|
||||
requests:
|
||||
cpu: '0.1'
|
||||
securityContext:
|
||||
privileged: false
|
||||
volumeMounts: []
|
||||
hostNetwork: false
|
||||
hostPID: false
|
||||
volumes: []
|
||||
@@ -1,10 +0,0 @@
|
||||
{
|
||||
"kind": "Namespace",
|
||||
"apiVersion": "v1",
|
||||
"metadata": {
|
||||
"name": "development",
|
||||
"labels": {
|
||||
"name": "development"
|
||||
}
|
||||
}
|
||||
}
|
||||
@@ -1,10 +0,0 @@
|
||||
{
|
||||
"kind": "Namespace",
|
||||
"apiVersion": "v1",
|
||||
"metadata": {
|
||||
"name": "production",
|
||||
"labels": {
|
||||
"name": "production"
|
||||
}
|
||||
}
|
||||
}
|
||||
@@ -67,24 +67,24 @@ One pattern this organization could follow is to partition the Kubernetes cluste
|
||||
|
||||
Let's create two new namespaces to hold our work.
|
||||
|
||||
Use the file [`namespace-dev.json`](/docs/tasks/administer-cluster/namespace-dev.json) which describes a development namespace:
|
||||
Use the file [`namespace-dev.json`](/examples/admin/namespace-dev.json) which describes a development namespace:
|
||||
|
||||
{{< code language="json" file="namespace-dev.json" >}}
|
||||
{{< codenew language="json" file="admin/namespace-dev.json" >}}
|
||||
|
||||
Create the development namespace using kubectl.
|
||||
|
||||
```shell
|
||||
$ kubectl create -f https://k8s.io/docs/tasks/administer-cluster/namespace-dev.json
|
||||
$ kubectl create -f https://k8s.io/examples/admin/namespace-dev.json
|
||||
```
|
||||
|
||||
Save the following contents into file [`namespace-prod.json`](/docs/tasks/administer-cluster/namespace-prod.json) which describes a production namespace:
|
||||
Save the following contents into file [`namespace-prod.json`](/examples/admin/namespace-prod.json) which describes a production namespace:
|
||||
|
||||
{{< code language="json" file="namespace-prod.json" >}}
|
||||
{{< codenew language="json" file="admin/namespace-prod.json" >}}
|
||||
|
||||
And then let's create the production namespace using kubectl.
|
||||
|
||||
```shell
|
||||
$ kubectl create -f https://k8s.io/docs/tasks/administer-cluster/namespace-prod.json
|
||||
$ kubectl create -f https://k8s.io/examples/admin/namespace-prod.json
|
||||
```
|
||||
|
||||
To be sure things are right, let's list all of the namespaces in our cluster.
|
||||
|
||||
@@ -140,20 +140,20 @@ One pattern this organization could follow is to partition the Kubernetes cluste
|
||||
|
||||
Let's create two new namespaces to hold our work.
|
||||
|
||||
Use the file [`namespace-dev.json`](/docs/tasks/administer-cluster/namespace-dev.json) which describes a development namespace:
|
||||
Use the file [`namespace-dev.json`](/examples/admin/namespace-dev.json) which describes a development namespace:
|
||||
|
||||
{{< code language="json" file="namespace-dev.json" >}}
|
||||
{{< codenew language="json" file="admin/namespace-dev.json" >}}
|
||||
|
||||
Create the development namespace using kubectl.
|
||||
|
||||
```shell
|
||||
$ kubectl create -f docs/tasks/administer-cluster/namespace-dev.json
|
||||
$ kubectl create -f https://k8s.io/examples/admin/namespace-dev.json
|
||||
```
|
||||
|
||||
And then let's create the production namespace using kubectl.
|
||||
|
||||
```shell
|
||||
$ kubectl create -f docs/tasks/administer-cluster/namespace-prod.json
|
||||
$ kubectl create -f https://k8s.io/examples/admin/namespace-prod.json
|
||||
```
|
||||
|
||||
To be sure things are right, list all of the namespaces in our cluster.
|
||||
|
||||
-13
@@ -1,13 +0,0 @@
|
||||
kind: InitializerConfiguration
|
||||
apiVersion: admissionregistration.k8s.io/v1alpha1
|
||||
metadata:
|
||||
name: pvlabel.kubernetes.io
|
||||
initializers:
|
||||
- name: pvlabel.kubernetes.io
|
||||
rules:
|
||||
- apiGroups:
|
||||
- ""
|
||||
apiVersions:
|
||||
- "*"
|
||||
resources:
|
||||
- persistentvolumes
|
||||
@@ -1,10 +0,0 @@
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: no-annotation
|
||||
labels:
|
||||
name: multischeduler-example
|
||||
spec:
|
||||
containers:
|
||||
- name: pod-with-no-annotation-container
|
||||
image: k8s.gcr.io/pause:2.0
|
||||
@@ -1,11 +0,0 @@
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: annotation-default-scheduler
|
||||
labels:
|
||||
name: multischeduler-example
|
||||
spec:
|
||||
schedulerName: default-scheduler
|
||||
containers:
|
||||
- name: pod-with-default-annotation-container
|
||||
image: k8s.gcr.io/pause:2.0
|
||||
@@ -1,11 +0,0 @@
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: annotation-second-scheduler
|
||||
labels:
|
||||
name: multischeduler-example
|
||||
spec:
|
||||
schedulerName: my-scheduler
|
||||
containers:
|
||||
- name: pod-with-second-annotation-container
|
||||
image: k8s.gcr.io/pause:2.0
|
||||
@@ -41,7 +41,7 @@ Successfully running cloud-controller-manager requires some changes to your clus
|
||||
since the cloud controller manager takes over labeling persistent volumes.
|
||||
* For the `cloud-controller-manager` to label persistent volumes, initializers will need to be enabled and an InitializerConifguration needs to be added to the system. Follow [these instructions](/docs/admin/extensible-admission-controllers.md#enable-initializers-alpha-feature) to enable initializers. Use the following YAML to create the InitializerConfiguration:
|
||||
|
||||
{{< code file="persistent-volume-label-initializer-config.yaml" >}}
|
||||
{{< codenew file="admin/cloud/pvl-initializer-config.yaml" >}}
|
||||
|
||||
Keep in mind that setting up your cluster to use cloud controller manager will change your cluster behaviour in a few ways:
|
||||
|
||||
@@ -71,7 +71,7 @@ For cloud controller managers not in Kubernetes core, you can find the respectiv
|
||||
|
||||
For providers already in Kubernetes core, you can run the in-tree cloud controller manager as a Daemonset in your cluster, use the following as a guideline:
|
||||
|
||||
{{< code file="cloud-controller-manager-daemonset-example.yaml" >}}
|
||||
{{< codenew file="admin/cloud/ccm-example.yaml" >}}
|
||||
|
||||
|
||||
## Limitations
|
||||
|
||||
Reference in New Issue
Block a user