I have a Kubernetes Job that has, for instance, parallelism set to 4. When this job is created, I might want to scale this out to, say, 8. But it seems like editing the Job and setting parallelism to 8 doesn't actually create more pods in the Job.
Am I missing something? Or is there no way to scale out a Job?
So as per job documentation you can still scale a Job running the following command:
kubectl scale job my-job --replicas=[VALUE]
Simple test shows that this option works right now as expected, but will be really deprecated in a future
kubectl scale job is DEPRECATED and will be removed in a future
version.
The ability to use kubectl scale jobs is deprecated. All other scale
operations remain in place, but the ability to scale jobs will be
removed in a future release.
The reason is: Deprecate kubectl scale job
Use below Job yaml as an example to create job:
apiVersion: batch/v1
kind: Job
metadata:
name: test-job
spec:
template:
spec:
containers:
- name: pi
image: perl
command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2010)"]
restartPolicy: Never
completions: 1000
parallelism: 5
Now lets test behavior:
kubectl describe jobs.batch test-job
Parallelism: 5
Completions: 1000
Start Time: Fri, 17 May 2019 16:58:36 +0200
Pods Statuses: 5 Running / 21 Succeeded / 0 Failed
kubectl get pods | grep test-job | grep Running
test-job-98mlv 1/1 Running 0 13s
test-job-fs2hb 1/1 Running 0 8s
test-job-l8n6v 1/1 Running 0 16s
test-job-lbh46 1/1 Running 0 13s
test-job-m8btl 1/1 Running 0 2s
Changing parallelism with kubectl scale:
kubectl scale jobs.batch test-job --replicas=10
kubectl describe jobs.batch test-job
Parallelism: 10
Completions: 1000
Start Time: Fri, 17 May 2019 16:58:36 +0200
Pods Statuses: 10 Running / 87 Succeeded / 0 Fail
kubectl get pods | grep test-job | grep Running
test-job-475zf 1/1 Running 0 10s
test-job-5k45h 1/1 Running 0 14s
test-job-8p99v 1/1 Running 0 22s
test-job-jtssp 1/1 Running 0 4s
test-job-ltx8f 1/1 Running 0 12s
test-job-mwnqb 1/1 Running 0 16s
test-job-n7t8b 1/1 Running 0 20s
test-job-p4bfs 1/1 Running 0 18s
test-job-vj8qw 1/1 Running 0 18s
test-job-wtjdl 1/1 Running 0 10s
And the last step that i believe will be the most interesting for you - you can always edit your job using kubectl patch command
kubectl patch job test-job -p '{"spec":{"parallelism":15}}'
kubectl describe jobs.batch test-job
Parallelism: 15
Completions: 1000
Start Time: Fri, 17 May 2019 16:58:36 +0200
Pods Statuses: 15 Running / 175 Succeeded / 0 Failed
kubectl get pods | grep test-job | grep Running | wc -l
15
kubectl scale doesn't support Job resource anymore. Here is working solution for me:
kubectl edit job [JOB_NAME]
set parallelism field to appropriate value for you.
It will create new pods or will terminate existing ones.
There's a scale command:
kubectl scale job my-job --replicas=[VALUE]
From docs:
kubectl scale causes the number of concurrently-running Pods to
change. Specifically, it changes the value of parallelism to the
[VALUE] you specify.
kubectl scale job, deprecated since 1.10, has been removed in 1.15.
Just use kubectl edit job to edit config yaml.
A bit old question, but since it has no accepted answer, here's the one I believe is the correct:
Since scale --replicas=... does not work for jobs anymore, the workaround is:
oc patch -n [namespace] job.batch/[jobname] -p '{"spec":{"parallelism":0}}'
or:
oc patch job -n [namespace] [jobname] -p '{"spec":{"parallelism":0}}'
kubectl patch cronjob -p "{"spec":{"jobTemplate":{"spec":{"parallelism":0, "completions":0}}}}" -n
NOTE: On Windows, that outer quotes has to be a double quote. For OpenShift (OC command), it accepts single quotes
Related
I have the following pods on my kubernetes (1.18.3) cluster:
NAME READY STATUS RESTARTS AGE
pod1 1/1 Running 0 14m
pod2 1/1 Running 0 14m
pod3 0/1 Pending 0 14m
pod4 0/1 Pending 0 14m
pod3 and pod4 cannot start because the node has capacity for 2 pods only. When pod1 finishes and quits, then the scheduler picks either pod3 or pod4 and starts it. So far so good.
However, I also have a high priority pod (hpod) that I'd like to start before pod3 or pod4 when either of the running pods finishes and quits.
So I created a priorityclass can be found in the kubernetes docs:
kind: PriorityClass
metadata:
name: high-priority-no-preemption
value: 1000000
preemptionPolicy: Never
globalDefault: false
description: "This priority class should be used for XYZ service pods only."
I've created the following pod yaml:
apiVersion: v1
kind: Pod
metadata:
name: hpod
labels:
app: hpod
spec:
containers:
- name: hpod
image: ...
resources:
requests:
cpu: "500m"
memory: "500Mi"
limits:
cpu: "500m"
memory: "500Mi"
priorityClassName: high-priority-no-preemption
Now the problem is that when I start the high prio pod with kubectl apply -f hpod.yaml, then the scheduler terminates a running pod to allow the high priority pod to start despite I've set 'preemptionPolicy: Never'.
The expected behaviour would be to postpone starting hpod until a currently running pod finishes. And when it does, then let hpod start before pod3 or pod4.
What am I doing wrong?
Prerequisites:
This solution was tested on Kubernetes v1.18.3, docker 19.03 and Ubuntu 18.
Also text editor is required (i.e. sudo apt-get install vim).
In Kubernetes documentation under How to disable preemption you can find Note:
Note: In Kubernetes 1.15 and later, if the feature NonPreemptingPriority is enabled, PriorityClasses have the option to set preemptionPolicy: Never. This will prevent pods of that PriorityClass from preempting other pods.
Also under Non-preempting PriorityClass you have information:
The use of the PreemptionPolicy field requires the NonPreemptingPriority feature gate to be enabled.
Later if you will check thoses Feature Gates info, you will find that NonPreemptingPriority is false, so as default it's disabled.
Output with your current configuration:
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-normal 1/1 Running 0 32s
nginx-normal-2 1/1 Running 0 32s
$ kubectl apply -f prio.yaml
pod/nginx-priority created$ kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-normal-2 1/1 Running 0 48s
nginx-priority 1/1 Running 0 8s
To enable preemptionPolicy: Never you need to apply --feature-gates=NonPreemptingPriority=true to 3 files:
/etc/kubernetes/manifests/kube-apiserver.yaml
/etc/kubernetes/manifests/kube-controller-manager.yaml
/etc/kubernetes/manifests/kube-scheduler.yaml
To check if this feature-gate is enabled you can check by using commands:
ps aux | grep apiserver | grep feature-gates
ps aux | grep scheduler | grep feature-gates
ps aux | grep controller-manager | grep feature-gates
For quite detailed information, why you have to edit thoses files please check this Github thread.
$ sudo su
# cd /etc/kubernetes/manifests/
# ls
etcd.yaml kube-apiserver.yaml kube-controller-manager.yaml kube-scheduler.yaml
Use your text editor to add feature gate to those files
# vi kube-apiserver.yaml
and add - --feature-gates=NonPreemptingPriority=true under spec.containers.command like in example bellow:
spec:
containers:
- command:
- kube-apiserver
- --feature-gates=NonPreemptingPriority=true
- --advertise-address=10.154.0.31
And do the same with 2 other files. After that you can check if this flags were applied.
$ ps aux | grep apiserver | grep feature-gates
root 26713 10.4 5.2 565416 402252 ? Ssl 14:50 0:17 kube-apiserver --feature-gates=NonPreemptingPriority=true --advertise-address=10.154.0.31
Now you have redeploy your PriorityClass.
$ kubectl get priorityclass
NAME VALUE GLOBAL-DEFAULT AGE
high-priority-no-preemption 1000000 false 12m
system-cluster-critical 2000000000 false 23m
system-node-critical 2000001000 false 23m
$ kubectl delete priorityclass high-priority-no-preemption
priorityclass.scheduling.k8s.io "high-priority-no-preemption" deleted
$ kubectl apply -f class.yaml
priorityclass.scheduling.k8s.io/high-priority-no-preemption created
Last step is to deploy pod with this PriorityClass.
TEST
$ kubectl get po
NAME READY STATUS RESTARTS AGE
nginx-normal 1/1 Running 0 4m4s
nginx-normal-2 1/1 Running 0 18m
$ kubectl apply -f prio.yaml
pod/nginx-priority created
$ kubectl get po
NAME READY STATUS RESTARTS AGE
nginx-normal 1/1 Running 0 5m17s
nginx-normal-2 1/1 Running 0 20m
nginx-priority 0/1 Pending 0 67s
$ kubectl delete po nginx-normal-2
pod "nginx-normal-2" deleted
$ kubectl get po
NAME READY STATUS RESTARTS AGE
nginx-normal 1/1 Running 0 5m55s
nginx-priority 1/1 Running 0 105s
Would there be any reason if I'm trying to run a pod on a k8s cluster which stays in the 'Completed' status forever but is never in ready status 'Ready 0/1' ... although there are core-dns , kube-proxy pods,etc running successfully scheduled under each node in the nodepool assigned to a k8s cluster ... all the worker nodes seems to be in healthy state
This sounds like the pod lifecycle has ended and the reasons is probably because your pod have finished the task it is meant for.
Something like next example will not do anything, it will be created successfully then started, will pull the image and then it will be marked as completed.
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: test-pod
image: busybox
resources:
Here is how it will look:
NAMESPACE NAME READY STATUS RESTARTS AGE
default my-pod 0/1 Completed 1 3s
default testapp-1 0/1 Pending 0 92m
default web-0 1/1 Running 0 3h2m
kube-system event-exporter-v0.2.5-7df89f4b8f-mc7kt 2/2 Running 0 7d19h
kube-system fluentd-gcp-scaler-54ccb89d5-9pp8z 1/1 Running 0 7d19h
kube-system fluentd-gcp-v3.1.1-gdr9l 2/2 Running 0 123m
kube-system fluentd-gcp-v3.1.1-pt8zp 2/2 Running 0 3h2m
kube-system fluentd-gcp-v3.1.1-xwhkn 2/2 Running 5 172m
kube-system fluentd-gcp-v3.1.1-zh29w 2/2 Running 0 7d19h
For this case, I will recommend you to check your yaml, check what kind of pod you are running? and what is it meant for?
Even, and with test purposes, you can add a command argument to keep it running.
command: ["/bin/sh","-c"]
args: ["command one; command two && command three"]
something like:
args: ["-c", "while true; do echo hello; sleep 10;done"]
The yaml with commands added would look like this:
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: test-pod
image: busybox
resources:
command: ["/bin/sh","-c"]
args: ["-c", "while true; do echo hello; sleep 10;done"]
Here is how it will look:
NAMESPACE NAME READY STATUS RESTARTS AGE
default my-pod 1/1 Running 0 8m56s
default testapp-1 0/1 Pending 0 90m
default web-0 1/1 Running 0 3h
kube-system event-exporter-v0.2.5-7df89f4b8f-mc7kt 2/2 Running 0 7d19h
kube-system fluentd-gcp-scaler-54ccb89d5-9pp8z 1/1 Running 0 7d19h
kube-system fluentd-gcp-v3.1.1-gdr9l 2/2 Running 0 122m
Another thing that will help is a kubectl describe pod $POD_NAME, to analyze this further.
This issue got nothing to do with k8s cluster or setup. It's mostly with your Dockerfile.
For the pod to be in running state, you need to have the container as an executable, for that usually an Entrypoint that specifies the instructions would solve the problem you are facing.
A better approach to resolve this or debug this particular issue would be, by running the respective docker container on a localmachine before deploying that onto k8s cluster.
The message Completed, most likely implies that the k8s started your container, then the container subsequently exited.
In Dockerfile, the ENTRYPOINT defines the process with pid 1 which the docker container should hold, otherwise it terminates, so whatever the pod is trying to do, you need to check whether the ENTRYPOINT command is looping, and doesn't die.
For side notes, Kubernetes will try to restart the pod, once it terminates but after few tries the pod status may turn into CrashLoopBackOff and you will see message something similar to Back-off restarting failed container.
I do not want to decrease the number of pods controlled by StatefulSet, and i think that decreasing pods is a dangerous operation in production env.
so... , is there some way ? thx ~
I'm not sure if this is what you are looking for but you can scale a StatefulSet
Use kubectl to scale StatefulSets
First, find the StatefulSet you want to scale.
kubectl get statefulsets <stateful-set-name>
Change the number of replicas of your StatefulSet:
kubectl scale statefulsets <stateful-set-name> --replicas=<new-replicas>
To show you an example, I've deployed a 2 pod StatefulSet called web:
$ kubectl get statefulsets.apps web
NAME READY AGE
web 2/2 60s
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
web-0 1/1 Running 0 63s
web-1 1/1 Running 0 44s
$ kubectl describe statefulsets.apps web
Name: web
Namespace: default
CreationTimestamp: Wed, 23 Oct 2019 13:46:33 +0200
Selector: app=nginx
Labels: <none>
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"apps/v1","kind":"StatefulSet","metadata":{"annotations":{},"name":"web","namespace":"default"},"spec":{"replicas":2,"select...
Replicas: 824643442664 desired | 2 total
Update Strategy: RollingUpdate
Partition: 824643442984
Pods Status: 2 Running / 0 Waiting / 0 Succeeded / 0 Failed
...
Now if we do scale this StatefulSet up to 5 replicas:
$ kubectl scale statefulset web --replicas=5
statefulset.apps/web scaled
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
web-0 1/1 Running 0 3m41s
web-1 1/1 Running 0 3m22s
web-2 1/1 Running 0 59s
web-3 1/1 Running 0 40s
web-4 1/1 Running 0 27s
$ kubectl get statefulsets.apps web
NAME READY AGE
web 5/5 3m56s
You do not have any downtime in already working pods.
i think that decreasing pods is a dangerous operation in production env.
I agree with you.
As Crou wrote, it is possible to do this operation with kubectl scale statefulsets <stateful-set-name> but this is an imperative operation and it is not recommended to do imperative operations in a production environment.
In a production environment it is better to use a declarative operation, e.g. have the number of replicas in a text file (e.g. stateful-set-name.yaml) and deploy them with kubectl apply -f <stateful-set-name>.yaml with this way of working, it is easy to store the yaml-files in Git so you have full control of all changes and can revert/rollback to a previous configuration. When you store the declarative files in a Git repository you can use a CICD solution e.g. Jenkins or ArgoCD to 1) validate the operation (e.g. not allow decrease) and 2) first deploy to a test-environment and see that it works, before applying the changes to the production environment.
I recommend the book (new edition) Kubernetes Up&Running 2nd ed that describes this procedure in Chapter 18 (new chapter).
I've installed Istio 1.1 RC on a fresh GKE cluster, using Helm, and enabled mTLS (some options omitted like Grafana and Kiali):
helm template istio/install/kubernetes/helm/istio \
--set global.mtls.enabled=true \
--set global.controlPlaneSecurityEnabled=true \
--set istio_cni.enabled=true \
--set istio-cni.excludeNamespaces={"istio-system"} \
--name istio \
--namespace istio-system >> istio.yaml
kubectl apply -f istio.yaml
Next, I installed the Bookinfo example app like this:
kubectl label namespace default istio-injection=enabled
kubectl apply -f istio/samples/bookinfo/platform/kube/bookinfo.yaml
kubectl apply -f istio/samples/bookinfo/networking/bookinfo-gateway.yaml
kubectl apply -f istio/samples/bookinfo/networking/destination-rule-all-mtls.yaml
Then I've gone about testing by following the examples at: https://istio.io/docs/tasks/security/mutual-tls/
My results show the config is incorrect, but the verification guide above doesn't provide any hints about how to fix or diagnose issues. Here's what I see:
istio/bin/istioctl authn tls-check productpage.default.svc.cluster.local
Stderr when execute [/usr/local/bin/pilot-discovery request GET /debug/authenticationz ]: gc 1 #0.015s 6%: 0.016+1.4+1.0 ms clock, 0.064+0.31/0.45/1.6+4.0 ms cpu, 4->4->1 MB, 5 MB goal, 4 P
gc 2 #0.024s 9%: 0.007+1.4+1.0 ms clock, 0.029+0.15/1.1/1.1+4.3 ms cpu, 4->4->2 MB, 5 MB goal, 4 P
HOST:PORT STATUS SERVER CLIENT AUTHN POLICY DESTINATION RULE
productpage.default.svc.cluster.local:9080 OK mTLS mTLS default/ default/istio-system
This appears to show that mTLS is OK. And the previous checks all pass, like checking the cachain is present, etc. The above check passes for all the bookinfo components.
However, the following checks show an issue:
1: Confirm that plain-text requests fail as TLS is required to talk to httpbin with the following command:
kubectl exec $(kubectl get pod -l app=productpage -o jsonpath={.items..metadata.name}) -c istio-proxy -- curl http://productpage:9080/productpage -o /dev/null -s -w '%{http_code}\n'
200 <== Error. Should fail.
2: Confirm TLS requests without client certificate also fail:
kubectl exec $(kubectl get pod -l app=productpage -o jsonpath={.items..metadata.name}) -c istio-proxy -- curl https://productpage:9080/productpage -o /dev/null -s -w '%{http_code}\n' -k
000 <=== Correct behaviour
command terminated with exit code 35
3: Confirm TLS request with client certificate succeed:
kubectl exec $(kubectl get pod -l app=productpage -o jsonpath={.items..metadata.name}) -c istio-proxy -- curl https://productpage:9080/productpage -o /dev/null -s -w '%{http_code}\n' --key /etc/certs/key.pem --cert /etc/certs/cert-chain.pem --cacert /etc/certs/root-cert.pem -k
000 <=== Incorrect. Should succeed.
command terminated with exit code 35
What else can I do to debug my installation? I've followed the installation process quite carefully. Here's my cluster info:
Kubernetes master is running at https://<omitted>
calico-typha is running at https://<omitted>/api/v1/namespaces/kube-system/services/calico-typha:calico-typha/proxy
GLBCDefaultBackend is running at https://<omitted>/api/v1/namespaces/kube-system/services/default-http-backend:http/proxy
Heapster is running at https://<omitted>/api/v1/namespaces/kube-system/services/heapster/proxy
KubeDNS is running at https://<omitted>/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
Metrics-server is running at https://<omitted>/api/v1/namespaces/kube-system/services/https:metrics-server:/proxy
Kubernetes version: 1.11.7-gke.4
I guess I'm after either a more comprehensive guide or some specific things I can check.
Edit: Additional info:
Pod status:
default ns:
NAME READY STATUS RESTARTS AGE
details-v1-68868454f5-l7srt 2/2 Running 0 3h
productpage-v1-5cb458d74f-lmf7x 2/2 Running 0 2h
ratings-v1-76f4c9765f-ttstt 2/2 Running 0 2h
reviews-v1-56f6855586-qszpm 2/2 Running 0 2h
reviews-v2-65c9df47f8-ztrss 2/2 Running 0 3h
reviews-v3-6cf47594fd-hq6pc 2/2 Running 0 2h
istio-system ns:
NAME READY STATUS RESTARTS AGE
grafana-7b46bf6b7c-2qzcv 1/1 Running 0 3h
istio-citadel-5bf5488468-wkmvf 1/1 Running 0 3h
istio-cleanup-secrets-release-1.1-latest-daily-zmw7s 0/1 Completed 0 3h
istio-egressgateway-cf8d6dc69-fdmw2 1/1 Running 0 3h
istio-galley-5bcd455cbb-7wjkl 1/1 Running 0 3h
istio-grafana-post-install-release-1.1-latest-daily-vc2ff 0/1 Completed 0 3h
istio-ingressgateway-68b6767bcb-65h2d 1/1 Running 0 3h
istio-pilot-856849455f-29nvq 2/2 Running 0 2h
istio-policy-5568587488-7lkdr 2/2 Running 2 3h
istio-sidecar-injector-744f68bf5f-h22sp 1/1 Running 0 3h
istio-telemetry-7ffd6f6d4-tsmxv 2/2 Running 2 3h
istio-tracing-759fbf95b7-lc7fd 1/1 Running 0 3h
kiali-5d68f4c676-qrxfd 1/1 Running 0 3h
prometheus-c4b6997b-6d5k9 1/1 Running 0 3h
Example destinationrule:
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
creationTimestamp: "2019-02-21T15:15:09Z"
generation: 1
name: productpage
namespace: default
spec:
host: productpage
subsets:
- labels:
version: v1
name: v1
trafficPolicy:
tls:
mode: ISTIO_MUTUAL
If you are using Istio 1.1 RC, you should be looking at the docs at https://preliminary.istio.io/ instead of https://istio.io/. The preliminary.istio.io site is always the working copy of the docs, corresponding to the next to be Istio release (1.1 currently).
That said, those docs are currently changing a lot day-to-day as they are being cleaned up and corrected during final testing before 1.1 is released, probably in the next couple of weeks.
A possible explanation for the plain text http request returning 200 in you test is that you may be running with permissive mode.
I'm new to Kubernetes. I try to scale my pods. First I started 3 pods:
./cluster/kubectl.sh run my-nginx --image=nginx --replicas=3 --port=80
There were starting 3 pods. First I tried to scale up/down by using a replicationcontroller but this did not exist. It seems to be a replicaSet now.
./cluster/kubectl.sh get rs
NAME DESIRED CURRENT AGE
my-nginx-2494149703 3 3 9h
I tried to change the amount of replicas described in my replicaset:
./cluster/kubectl.sh scale --replicas=5 rs/my-nginx-2494149703
replicaset "my-nginx-2494149703" scaled
But I still see my 3 original pods
./cluster/kubectl.sh get pods
NAME READY STATUS RESTARTS AGE
my-nginx-2494149703-04xrd 1/1 Running 0 9h
my-nginx-2494149703-h3krk 1/1 Running 0 9h
my-nginx-2494149703-hnayu 1/1 Running 0 9h
I would expect to see 5 pods.
./cluster/kubectl.sh describe rs/my-nginx-2494149703
Name: my-nginx-2494149703
Namespace: default
Image(s): nginx
Selector: pod-template-hash=2494149703,run=my-nginx
Labels: pod-template-hash=2494149703
run=my-nginx
Replicas: 3 current / 3 desired
Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed
Why isn't it scaling up? Do I also have to change something in the deployment?
I see something like this when I describe my rs after scaling up:
(Here I try to scale from one running pod to 3 running pods). But it remains one running pod. The other 2 are started and killed immediatly
34s 34s 1 {replicaset-controller } Normal SuccessfulCreate Created pod: my-nginx-1908062973-lylsz
34s 34s 1 {replicaset-controller } Normal SuccessfulCreate Created pod: my-nginx-1908062973-5rv8u
34s 34s 1 {replicaset-controller } Normal SuccessfulDelete Deleted pod: my-nginx-1908062973-lylsz
34s 34s 1 {replicaset-controller } Normal SuccessfulDelete Deleted pod: my-nginx-1908062973-5rv8u
This is working for me
kubectl scale --replicas=<expected_replica_num> deployment <deployment_label_name> -n <namespace>
Example
# kubectl scale --replicas=3 deployment xyz -n my_namespace
TL;DR: You need to scale your deployment instead of the replica set directly.
If you try to scale the replica set, then it will (for a very short time) have a new count of 5. But the deployment controller will see that the current count of the replica set is 5 and since it knows that it is supposed to be 3, it will reset it back to 3. By manually modifying the replica set that was created for you, you are fighting with the system controller (which is untiring and will pretty much always outlast you).
kubectl run my-nginx --image=nginx --replicas=3 --port=80 in this kubectl run will create a deployment or job to manage the created container(s).
Deployment-->ReplicaSet-->Pod this is how kubernetes works.
If you change the bottom-level object, its higher-level object will undo your change.You have to change the top-level object.
scale it down to zero and then to the number of pods you required (guess it equals to 3)
kubectl scale deployment <deployment-name> --replicas=0 -n <namespace>
kubectl scale deployment <deployment-name> --replicas=3 -n <namespace>
Not sure if this is the best way as I'm starting out with kubernetes, but I did this by updating my yaml file
# app.yaml
apiVersion: apps/v1
...
spec:
replicas: <new value>
and running $ kubectl scale -f app.yaml --replicas=<new value>
you can verify your new number of replicas by running $ kubectl get pods
In my case I was also interested in scaling back my VMs, on google cloud. I did this with $ gcloud container clusters resize appName --size=1 --zone "my-zone"
Below example shows how you should scale up/down your "pods/resource/deployments".
k8smaster#k8smaster:~/debashish$ more createdeb_deployment1.yaml
---
apiVersion: apps/v1beta2
kind: Deployment
metadata:
name: debdeploy-webserver
spec:
replicas: 1
selector:
matchLabels:
app: debdeploy1webserver
template:
metadata:
labels:
app: debdeploy1webserver
spec:
containers:
-
image: "docker.io/debu3645/debapachewebserver:v1"
name: deb-deploy1-container
ports:
-
containerPort: 6060
deployment created -->
**kubectl -n debns1 create -f createdeb_deployment1.yaml**
k8smaster#k8smaster:~/debashish$ `kubectl scale --replicas=5 **deployment**/debdeploy-webserver -n debns1`
(Scale up 5 deployments)
k8smaster#k8smaster:~/debashish$ kubectl get pods -n debns1
NAME READY STATUS RESTARTS AGE
debdeploy-webserver-7cf4fb74c5-8wvzx 1/1 Running 0 16s
debdeploy-webserver-7cf4fb74c5-jrf6v 1/1 Running 0 16s
debdeploy-webserver-7cf4fb74c5-m9fpw 1/1 Running 0 16s
debdeploy-webserver-7cf4fb74c5-q9n7r 1/1 Running 0 16s
debdeploy-webserver-7cf4fb74c5-ttw6p 1/1 Running 1 19h
resourcepod-deb1 1/1 Running 5 6d18h
k8smaster#k8smaster:~/debashish$ **kubectl get ep -n debns1**
NAME ENDPOINTS AGE
frontend-svc-deb 192.168.1.10:80,192.168.1.11:80,192.168.1.12:80 + 2 more... 18h
frontend-svc1-deb 192.168.1.8:80 14d
frontend-svc2-deb 192.168.1.8:80 5d19h
k8smaster#k8smaster:~/debashish$ **kubectl scale --replicas=2** deployment/debdeploy-webserver -n debns1
(Scale down from 5 to 2)
deployment.extensions/debdeploy-webserver scaled
k8smaster#k8smaster:~/debashish$ **kubectl get pods -n debns1**
NAME READY STATUS RESTARTS AGE
debdeploy-webserver-7cf4fb74c5-8wvzx 1/1 Terminating 0 35m
debdeploy-webserver-7cf4fb74c5-jrf6v 1/1 Terminating 0 35m
debdeploy-webserver-7cf4fb74c5-m9fpw 1/1 Terminating 0 35m
debdeploy-webserver-7cf4fb74c5-q9n7r 1/1 Running 0 35m
debdeploy-webserver-7cf4fb74c5-ttw6p 1/1 Running 1 19h
resourcepod-deb1 1/1 Running 5 6d19h
k8smaster#k8smaster:~/debashish$ **kubectl get pods -n debns1**
NAME READY STATUS RESTARTS AGE
debdeploy-webserver-7cf4fb74c5-q9n7r 1/1 Running 0 37m
debdeploy-webserver-7cf4fb74c5-ttw6p 1/1 Running 1 19h
resourcepod-deb1 1/1 Running 5 6d19h
k8smaster#k8smaster:~/debashish$ kubectl **scale --current-replicas=4 --replicas=2** deployment/debdeploy-webserver -n debns1 (Check the current no. of deployments. If current replication is 4, then bring it down to 2, else dont do anything)
error: Expected replicas to be 4, was 2
k8smaster#k8smaster:~/debashish$ **kubectl scale --current-replicas=3 --replicas=10 deployment/debdeploy-webserver -n debns1**
error: Expected replicas to be 3, was 2
k8smaster#k8smaster:~/debashish$ **kubectl scale --current-replicas=2 --replicas=10 deployment/debdeploy-webserver -n debns1**
deployment.extensions/debdeploy-webserver scaled
k8smaster#k8smaster:~/debashish$ **kubectl get pods -n debns1**
NAME READY STATUS RESTARTS AGE
debdeploy-webserver-7cf4fb74c5-46bxg 1/1 Running 0 6s
debdeploy-webserver-7cf4fb74c5-d6qsx 0/1 ContainerCreating 0 6s
debdeploy-webserver-7cf4fb74c5-fdq6v 1/1 Running 0 6s
debdeploy-webserver-7cf4fb74c5-gd87t 1/1 Running 0 6s
debdeploy-webserver-7cf4fb74c5-kqdbj 0/1 ContainerCreating 0 6s
debdeploy-webserver-7cf4fb74c5-q9n7r 1/1 Running 0 47m
debdeploy-webserver-7cf4fb74c5-qjvm6 1/1 Running 0 6s
debdeploy-webserver-7cf4fb74c5-skxq4 0/1 ContainerCreating 0 6s
debdeploy-webserver-7cf4fb74c5-ttw6p 1/1 Running 1 19h
debdeploy-webserver-7cf4fb74c5-wlc7q 0/1 ContainerCreating 0 6s
resourcepod-deb1 1/1 Running 5 6d19h
for deployment
kubectl scale deployment <deployment-name> --replicas=3 -n <namespace>
for statefulset
kubectl scale statefulsets <stateful-set-name> --replicas=3 -n <namespace>