Command line tools
This appendix provides introduction to Command line tools like Helm cli, kubectl, cloudctl and a cheat sheet for kubectl/cloudctl that are handy in production environment.
This appendix has the following sections:
Helm command line interface (helmcli)
The helmcli commands manage the application lifecycle in IBM Cloud Private cluster. Before you set up the Helm CLI, you need to perform the following steps:
1. Install the Kubernetes command line tool, kubectl, and configure access to your cluster. See Kubernetes section on page 353.
2. Install the IBM Cloud Private CLI and log in to your cluster. See IBM Cloud Private CLI section on page 350.
3. Obtain access to the boot node and the cluster administrator account, or request that someone with that access level create your certificate. If you cannot access the cluster administrator account, you need an IBM Cloud Private account that is assigned to the administrator role for a team and can access the kube-system namespace.
Installing the Helm CLI
You can install the Helm CLI by downloading it from the Helm GitHub site. Complete the following steps to install the Helm CLI:
1. Download the Helm v2.9.1 binary from helm GitHub site.
2. Make a helm-unpacked directory and unpack the installation file into that directory with the following commands:
mkdir helm-unpacked
tar -xvzf ./<path_to_installer> -C helm-unpacked
3. Change the file to an executable, then move the file to your directory:
a. For Linux and MacOS, run the following commands to change the permissions and move the file:
chmod 755 ./helm-unpacked/<unpacked_dir>/helm
sudo mv ./helm-unpacked/<unpacked_dir>/helm /usr/local/bin/helm
b. For Windows, rename the downloaded file to Helm and place the file in a directory that is listed in the PATH environment variable.
4. Delete the installer and the unpacked archives:
rm -rf ./helm-unpacked ./<path_to_installer>.
Verifying the installation
Perform the following steps to verify the installation:
1. If you are using Helm 2.9.1, you must set HELM_HOME:
export HELM_HOME=~/.helm
2. Initialize your Helm CLI. Do not use the --upgrade flag with the helm init command. Adding the --upgrade flag replaces the server version of Helm Tiller that is installed with IBM Cloud Private.
3. For environments with Internet access, run the following command:
helm init --client-only
4. For environments that do not have Internet access, run the following command:
helm init --client-only --skip-refresh
5. Verify that the Helm CLI is initialized. Run the following command:
helm version --tls
The output should be similar to Example A-1.
Example A-1 Helm CLI is initialized
: Client: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"} Server: &version.Version{SemVer:"v2.9.1+icp", GitCommit:"843201eceab24e7102ebb87cb00d82bc973d84a7", GitTreeState:"clean"}
Using helmcli
Follow the steps to review a list of available or installed packages:
1. Add a Helm repository. To add the Kubernetes Incubator repository, run the following command:
helm repo add incubator https://kubernetes-charts-incubator.storage.googleapis.com/
2. View the available charts by running the following command:
helm search -l
3. Install a chart. Run the following command:
helm install --name=release_name stable/chart_in_repo --tls
4. In the above command, release_name is the name for the release to be created from the chart, and chart_in_repo is the name of the available chart to install. For example, to install the WordPress chart, run the following command:
helm install --name=my-wordpress stable/wordpress --tls
5. List the releases by running the following command:
helm list --tls
The output should be similar to Example A-2.
Example A-2 helm list charts
NAME REVISION UPDATED STATUS CHART NAMESPACE
my-wordpress 1 Wed Jun 28 22:15:13 2017 DEPLOYED wordpress-0.6.5 default
6. To remove a release, run the following command:
helm delete release_name --purge --tls
7. In this command, release_name is the name of the release to remove. For example, to remove the WordPress release, run the following command:
helm delete my-wordpress --purge --tls
IBM Cloud Private CLI (cloudctl)
The cloudctl commands are executed to view information about your IBM Cloud Private cluster, manage your cluster, install Helm charts, and more.
Installing the IBM Cloud Private CLI
After IBM Cloud Private is installed, install the CLI on Windows, Linux, or macOS using the following steps:
1. Synchronize the clocks between the client computer and the nodes in the IBM Cloud Private cluster. To synchronize your clocks, use the network time protocol (NTP). For more information about setting up the NTP, see the user documentation for your operating system.
2. From the IBM Cloud Private management console, click Menu → Command Line Tools → Cloud Private CLI to download the installer by using a curl command. Copy and run the curl command for your operating system, then continue the installation procedure.
3. Choose the curl command for the applicable operating system. For example, you can run the following command for macOS:
curl -kLo <install_file> https://<cluster ip>:<port>/api/cli/cloudctl-darwin-amd64
4. After you run the curl command for your operating system, continue to install the IBM Cloud Private CLI.
5. To install the IBM Cloud Private CLI, run the command that matches your node architecture. <path_to_installer> is the path to the directory where you downloaded the CLI file and <install_file> is the downloaded file name. For Linux and MacOS, run the following commands to change the permissions and move the file:
chmod 755 <path_to_installer>/<install_file>
sudo mv <path_to_installer>/<install_file> /usr/local/bin/cloudctl
6. For Windows, rename the downloaded file to cloudctl and place the file on the PATH environment variable.
7. Confirm that the IBM Cloud Private CLI is installed:
cloudctl --help
The IBM Cloud Private CLI usage is displayed.
8. Log in to your cluster:
cloudctl login -a https://<cluster_host_name>:8443 --skip-ssl-validation
Where cluster_host_name is the external host name or IP address for your master or leading master node.
9. Use the IBM Cloud Private CLI to view information about your first cluster, install more content for your cluster, or configure more clusters. If you use the IBM Cloud Private CLI to configure a new cluster, you can use the CLI to add or remove worker nodes to and from it.
10. You can configure the single sign-on by using cloudctl commands. More information on how to configure is documented here:
General cloudctl commands
To log in to IBM Cloud Private cluster use cloudctl login to interactively enter the password, which is invisible, as shown in Figure A-1.
Figure A-1 The cloudctl login
You can follow the prompt for choosing the account and namespace or provide those options except the username and password in the command. The same action can be performed in one command:
cloudctl login [-a CLUSTER_URL] [-c ACCOUNT_ID or ACCOUNT_NAME] [-n namespace] [--skip-ssl-validation]
 
Important: Providing your password as a command line option is not recommended. Your password might be visible to others and might be recorded in your shell history.
cloudctl logout will log out the session from the IBM Cloud Private cluster.
For more information, see IBM Knowledge center or use cloudctl - -help or cloudctl -h as shown in Figure A-2 on page 352.
 
Figure A-2 The cloudctl help command
To manage the API keys, IDs, and the service policies of an IBM Cloud Private cluster, use the cloudctl iam commands. Run the following to see the list of available commands: cloudctl iam - -help.
For more information about using the cloudctl iam commands visit https://www.ibm.com/support/knowledgecenter/en/SSBS6K_3.1.0/manage_cluster/cli_iam_commands.html.
cloudctl catalog commands
To manage the Helm charts, use the following cloudctl catalog commands:
•cloudctl catalog charts: Lists helm charts of the cluster helm repositories.
•cloudctl catalog create-archive: Creates a catalog archive files containing Docker images and Helm charts.
•cloudctl catalog delete-chart - delete-helm-chart: Deletes a Helm chart from the IBM Cloud Private internal registry.
•cloudctl catalog load-archive - load-ppa-archive: Load Docker images and Helm charts from a catalog archive file.
•cloudctl catalog load-chart - load-helm-chart: Loads a Helm chart archive to an IBM Cloud Private cluster.
•cloudctl catalog load-images: Loads Docker images into an IBM Cloud Private internal Docker registry.
•cloudctl catalog repos: Lists helm repositories.
cloud cm commands
To manage an IBM Cloud Private cluster, use the following cloud cm commands:
•cloudctl cm credentials-set-openstack: Sets the infrastructure account credentials for the OpenStack cloud provider.
•cloudctl cm credentials-set-vmware: Sets the infrastructure account credentials for the VMware cloud provider.
•cloudctl cm credentials-unset: Removes cloud provider credentials. After you remove the credentials, you cannot access the cloud provider.
•cloudctl cm machine-type-add-openstack: Adds an openstack machine type. A machine type determines the number of CPUs, the amount of memory, and disk space that is available to the node.
•cloudctl cm machine-type-add-vmware: Adds a VMware machine type. A machine type determines the number of CPUs, the amount of memory, and disk space that is available to the node.
•cloudctl cm machine-types: Lists available machine types. A machine type determines the number of CPUs, the amount of memory, and disk space that is available to the node.
•cloudctl cm master-get: Views the details about a master node.
•cloudctl cm masters: Lists all master nodes.
•cloudctl cm nodes: Lists all nodes.
•cloudctl cm proxies: Lists all proxy nodes.
•cloudctl cm proxy-add: Adds a proxy node to a cluster.
•cloudctl cm proxy-get: Views the details about a proxy node.
•cloudctl cm proxy-rm: Removes proxy nodes.
•cloudctl cm registry-init: Initializes cluster image registry.
•cloudctl cm worker-add: Adds a worker node to a cluster.
•cloudctl cm worker-get: Views the details about a worker node.
•cloudctl cm worker-rm: Removes worker nodes.
•cloudctl cm workers: Lists all worker nodes in an existing cluster.
Kubectl
To manage Kubernetes clusters and IBM Cloud Private you can use the kubectl commands. In this section we show you some of the kubectl commands that would help you manage your cluster and IBM Cloud Private Installation.
To see the details about how to install the kubectl see the Knowledge Center link: https://www.ibm.com/support/knowledgecenter/en/SSBS6K_3.1.2/manage_cluster/install_kubectl.html.
After installing the kubectl command line, you need to perform the authentication for the IBM Cloud Private cluster that you want to manage. For more information on kubectl authentication see the following link: https://www.ibm.com/support/knowledgecenter/en/SSBS6K_3.1.2/manage_cluster/install_kubectl.html.
 
Tip: You can run kubectl --help to see the options for this command. See Example A-3.
Example A-3 The kubectl --help command
kubectl --help
kubectl get --help
kubectl describe pods--help
As you can see in Example A-3, it is possible to see the details specifically for each command.
The full list of options is available when you run kubectl as shown on Example A-4.
Example A-4 The kubectl command options
kubectl
kubectl controls the Kubernetes cluster manager.
 
Find more information at: https://kubernetes.io/docs/reference/kubectl/overview/
 
Basic Commands (Beginner):
create Create a resource from a file or from stdin.
expose Take a replication controller, service, deployment or pod and expose it as a new Kubernetes Service
run Run a particular image on the cluster
set Set specific features on objects
 
Basic Commands (Intermediate):
explain Documentation of resources
get Display one or many resources
edit Edit a resource on the server
delete Delete resources by filenames, stdin, resources and names, or by resources and label selector
 
Deploy Commands:
rollout Manage the rollout of a resource
scale Set a new size for a Deployment, ReplicaSet, Replication Controller, or Job
autoscale Auto-scale a Deployment, ReplicaSet, or ReplicationController
 
Cluster Management Commands:
certificate Modify certificate resources.
cluster-info Display cluster info
top Display Resource (CPU/Memory/Storage) usage.
cordon Mark node as unschedulable
uncordon Mark node as schedulable
drain Drain node in preparation for maintenance
taint Update the taints on one or more nodes
 
Troubleshooting and Debugging Commands:
describe Show details of a specific resource or group of resources
logs Print the logs for a container in a pod
attach Attach to a running container
exec Execute a command in a container
port-forward Forward one or more local ports to a pod
proxy Run a proxy to the Kubernetes API server
cp Copy files and directories to and from containers.
auth Inspect authorization
 
Advanced Commands:
apply Apply a configuration to a resource by filename or stdin
patch Update field(s) of a resource using strategic merge patch
replace Replace a resource by filename or stdin
wait Experimental: Wait for a specific condition on one or many resources.
convert Convert config files between different API versions
 
Settings Commands:
label Update the labels on a resource
annotate Update the annotations on a resource
completion Output shell completion code for the specified shell (bash or zsh)
 
Other Commands:
alpha Commands for features in alpha
api-resources Print the supported API resources on the server
api-versions Print the supported API versions on the server, in the form of "group/version"
config Modify kubeconfig files
plugin Provides utilities for interacting with plugins.
version Print the client and server version information
 
Usage:
kubectl [flags] [options]
 
Use "kubectl <command> --help" for more information about a given command.
Use "kubectl options" for a list of global command-line options (applies to all commands).
 
The full list of commands for kubectl can be found at https://kubernetes.io/docs/reference/kubectl/overview/
In this section we describe the commonly used commands for server management and troubleshooting.
kubectl get
The kubectl get command is used to get information about the Kubernetes environment such as resources, pods and node information.
The kubectl get command runs against the namespace that was selected during the login. If needed it could be specified with the flag -n <namespace>.
kubectl get namespace
The command kubectl get namespace is used to get all namespaces from the cluster, and also to get information on whether the namespace is active or not. See Example A-5 as a sample output.
Example A-5 The kubectl get namespace command
kubectl get namespace
NAME STATUS AGE
cert-manager Active 13d
default Active 13d
development Active 13d
finance Active 13d
ibmcom Active 13d
istio-system Active 13d
kube-public Active 13d
kube-system Active 13d
marketing Active 13d
platform Active 13d
services Active 13d
kubectl get nodes
This command is used to get the nodes that are part of a cluster, including their roles and status.
If you need more information, you can see the command kubectl get nodes -o wide.
Example A-6 shows the output of the command kubectl get nodes.
Example A-6 The kubectl get node command
NAME STATUS ROLES AGE VERSION
10.21.9.173 Ready etcd,master 13d v1.12.4+icp-ee
10.21.9.176 Ready proxy 13d v1.12.4+icp-ee
10.21.9.177 Ready management 13d v1.12.4+icp-ee
10.21.9.179 Ready va 13d v1.12.4+icp-ee
10.21.9.180 Ready worker 13d v1.12.4+icp-ee
10.21.9.181 Ready worker 13d v1.12.4+icp-ee
10.21.9.184 Ready worker 13d v1.12.4+icp-ee
Optionally, if you need to get the status or information about a specific node, you can specify the name of the node in the command.
kubectl get pods
The kubectl get pods command is used to get the list of pods running in a specific namespace. By adding the flag --all-namespaces, you can list all pods of a specific cluster.
See the output of it at Example A-7.
Example A-7 The kubectl get pods command
[root@icp-312-node-1 cluster]# kubectl get pods --all-namespaces
NAMESPACE NAME READY STATUS RESTARTS AGE
cert-manager ibm-cert-manager-cert-manager-7c77d68c7f-sp64b 1/1 Running 0 13d
development test-ibm-nginx-dev-nginx-8677c69574-bqk8w 1/1 Running 0 12d
kube-system audit-logging-fluentd-ds-4xkjp 1/1 Running 0 13d
kube-system audit-logging-fluentd-ds-bssb8 1/1 Running 0 13d
kube-system audit-logging-fluentd-ds-h6vch 1/1 Running 0 13d
kube-system audit-logging-fluentd-ds-j2px9 1/1 Running 0 13d
kube-system audit-logging-fluentd-ds-jtfv4 1/1 Running 0 13d
This command is useful when trying to get the status of the pod. It is frequently used when troubleshooting a pod issue as described in Chapter 8, “Troubleshooting” on page 273.
kubectl logs
The kubectl logs command shows the logs of a resource or a pod. This command is useful when troubleshooting an application and when you need more information about it.
See Example A-8 to get the logs from a container.
Example A-8 The kubectl logs command
kubectl logs web-terminal-597c796cc-r5czh -n kube-system
App listening on https://0.0.0.0:443
Created terminal with PID: 184 for user: admin
Connected to terminal 184
admin login complete with exit code 0:
Targeted account mycluster Account (id-mycluster-account)
 
Select a namespace:
1. cert-manager
2. default
3. development
4. finance
5. ibmcom
6. istio-system
7. kube-public
8. kube-system
9. marketing
10. platform
11. services
Enter a number> 1
Targeted namespace cert-manager
The kubectl exec command is used to run commands on pods, such as running the name resolution, or even accessing the container shell.
Example A-9 shows how to get access to the container’s shell.
Example A-9 Accessing the pod shell
[root@icp-312-node-1 ~]#kubectl exec web-terminal-597c796cc-r5czh -n kube-system -i -t -- bash -il
Welcome to the IBM Cloud Private Web Terminal
 
Type "cloudctl" to use IBM Cloud Private CLI
Run "ls -m /usr/local/bin" for a list of tools installed
 
root@web-terminal-597c796cc-r5czh:/usr/local/web-terminal# ls
app.js index.html node_modules package.json style.css
certs main.js package-lock.json static
root@web-terminal-597c796cc-r5czh:/usr/local/web-terminal#
To return to the server, just type exit.
It is also possible to run a specific command, such as ls -ltr /tmp. See Example A-10.
Example A-10 Running ls -ltr /tmp
[root@icp-312-node-1 ~]# kubectl exec web-terminal-597c796cc-r5czh -n kube-system -i -t -- ls -ltr /tmp
total 0
-rw------- 1 admin nogroup 0 Feb 27 22:43 sh-thd-939284318
[root@icp-312-node-1 ~]#
As you can see in this example, this command runs the pod as a local VM.
kubectl describe
The command kubectl describe is used to get information about pods, nodes, and other Kubernetes resources:
To get information on a specific node run:
kubectl describe nodes <node_Name>
To get information on a specific pod run:
kubectl describe pods/nginx
To get information on all pods run:
kubectl describe pods
To get information on pods by label (for example name=myLabel) run:
kubectl describe po -l name=myLabel
Example A-11 shows an example.
Example A-11 The describe nodes command output
kubectl describe nodes
Name: 10.21.9.173
Roles: etcd,master
Labels: beta.kubernetes.io/arch=amd64
beta.kubernetes.io/os=linux
etcd=true
kubernetes.io/hostname=10.21.9.173
master=true
node-role.kubernetes.io/etcd=true
node-role.kubernetes.io/master=true
role=master
Annotations: node.alpha.kubernetes.io/ttl: 0
volumes.kubernetes.io/controller-managed-attach-detach: true
CreationTimestamp: Wed, 27 Feb 2019 12:09:04 -0800
Taints: dedicated=infra:NoSchedule
Unschedulable: false
Conditions:
Type Status LastHeartbeatTime LastTransitionTime Reason Message
---- ------ ----------------- ------------------ ------ -------
OutOfDisk False Wed, 13 Mar 2019 14:39:25 -0700 Wed, 27 Feb 2019 12:09:04 -0800 KubeletHasSufficientDisk kubelet has sufficient disk space available
MemoryPressure False Wed, 13 Mar 2019 14:39:25 -0700 Wed, 27 Feb 2019 12:09:04 -0800 KubeletHasSufficientMemory kubelet has sufficient memory available
DiskPressure False Wed, 13 Mar 2019 14:39:25 -0700 Wed, 27 Feb 2019 12:09:04 -0800 KubeletHasNoDiskPressure kubelet has no disk pressure
PIDPressure False Wed, 13 Mar 2019 14:39:25 -0700 Wed, 27 Feb 2019 12:09:04 -0800 KubeletHasSufficientPID kubelet has sufficient PID available
Ready True Wed, 13 Mar 2019 14:39:25 -0700 Wed, 27 Feb 2019 12:36:18 -0800 KubeletReady kubelet is posting ready status
Addresses:
InternalIP: 10.21.9.173
Hostname: 10.21.9.173
Capacity:
cpu: 8
ephemeral-storage: 245640Mi
hugepages-1Gi: 0
hugepages-2Mi: 0
memory: 16266504Ki
pods: 80
Allocatable:
cpu: 7600m
ephemeral-storage: 243492Mi
hugepages-1Gi: 0
hugepages-2Mi: 0
memory: 15115528Ki
pods: 80
System Info:
Machine ID: f7bbe4af93974cbfa5c55b68c011d41c
System UUID: C08E1133-DBDD-4345-BEB9-6BABCEE56B08
Boot ID: e2216849-3090-4860-94da-b3c1a34e3823
Kernel Version: 3.10.0-862.14.4.el7.x86_64
OS Image: Red Hat Enterprise Linux Server 7.4 (Maipo)
Operating System: linux
Architecture: amd64
Container Runtime Version: docker://18.3.1
Kubelet Version: v1.12.4+icp-ee
Kube-Proxy Version: v1.12.4+icp-ee
Non-terminated Pods: (37 in total)
Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits
--------- ---- ------------ ---------- --------------- -------------
cert-manager ibm-cert-manager-cert-manager-7c77d68c7f-sp64b 0 (0%) 0 (0%) 0 (0%) 0 (0%)
kube-system audit-logging-fluentd-ds-j2px9 0 (0%) 0 (0%) 0 (0%) 0 (0%)
kube-system auth-apikeys-pjj8w 200m (2%) 1 (13%) 300Mi (2%) 1Gi (6%)
kube-system auth-idp-5qmct 300m (3%) 3200m (42%) 768Mi (5%) 3584Mi (24%)
kube-system auth-pap-7j8hs 150m (1%) 1200m (15%) 456Mi (3%) 1536Mi (10%)
kube-system auth-pdp-bmgqc 600m (7%) 200m (2%) 768Mi (5%) 512Mi (3%)
kube-system calico-kube-controllers-79ff4c4cff-lwzsk 250m (3%) 0 (0%) 100Mi (0%) 0 (0%)
kube-system calico-node-2krkk 300m (3%) 0 (0%) 150Mi (1%) 0 (0%)
kube-system catalog-ui-2srgr 300m (3%) 300m (3%) 300Mi (2%) 300Mi (2%)
kube-system heapster-745c899b68-pg4zx 20m (0%) 0 (0%) 64Mi (0%) 0 (0%)
kube-system helm-api-567f86b4f6-djtdw
Allocated resources:
(Total limits may be over 100 percent, i.e., overcommitted.)
Resource Requests Limits
-------- -------- ------
cpu 5083m (66%) 10206m (134%)
memory 6878Mi (46%) 12364Mi (83%)
Events: <none>
With the previous command it is possible to see the details for the running nodes, including pods and used resources.
Cheat sheet for production environment
In the following section we list some of the commands that are commonly used in a production environment.
Use kubectl drain to remove a node from service
You can use kubectl drain to safely evict all of your pods from a node before you perform maintenance on the node (for example for kernel upgrade or hardware maintenance). Safe evictions allow the pod’s containers to gracefully terminate and respect the PodDisruptionBudgets that you have specified:
1. First, identify the name of the node you wish to drain. You can list all of the nodes in your cluster with:
kubectl get nodes
2. Next, tell Kubernetes to drain the node:
kubectl drain <node name>
3. Once it returns without giving an error, you can power down the node (or on a cloud platform, delete the virtual machine backing the node). If you leave the node in the cluster during the maintenance operation, you need to run:
kubectl uncordon <node name>
This will instruct Kubernetes that it can resume scheduling of new pods onto the node.
Enabling autocomplete for kubectl
It might be difficult to remember all of the commands and their arguments for the kubectl command. kubectl provides an autocomplete function to help you remember the commands and their arguments. You can enable kubectl autocompletion in your current shell using the following command:
source <(kubectl completion bash)
Removing a pod from a service
Let’s assume we have a service backed by a number of pods. If one of the pods starts misbehaving we need to find out the root cause for the same. We need to remove the failing pod from the list of pods to investigate the problem later.
Suppose we have pod foo with the label ‘test’. We update the pod foo by removing the label named test if it exists with the following command:
$ kubectl label pods foo test-
As you remove the label, the pod will be out of service and deployment will spawn a new pod with the label test.
Editing kubernetes resources
Sometimes in a production environment you need to fine tune Kubernetes resources by editing them. You can edit the resources using kubectl edit <resource_name>.
Example A-12 shows changing the port number for the service production.
Example A-12 Change the port number for the service
kubectl edit svc/product
app: product
name: product
namespace: default
resourceVersion: "2336715"
selfLink: /api/v1/namespaces/default/services/product
uid: de98218d-42ea-11e9-9217-0016ac1010ec
spec:
clusterIP: 10.0.0.221
ports:
- name: http
port: 8000
protocol: TCP
targetPort: 8000
Taints and tolerations
Taints and tolerations work together to ensure that pods are not scheduled onto inappropriate nodes. One or more taints are applied to a node; this marks that the node should not accept any pods that do not tolerate the taints. Tolerations are applied to pods, and allow (but do not require) the pods to schedule onto nodes with matching taints.
You add a taint to a node using kubectl taint. For example:
kubectl taint nodes node1 key=value:NoSchedule
places a taint on node node1. The taint has a key, a key value, and the taint effect NoSchedule parameter. This means that no pod will be able to schedule onto node1 unless it has a matching toleration.To remove the taint added by the command above, you can run:
kubectl taint nodes node1 key:NoSchedule-
You specify a toleration for a pod in the PodSpec. Both of the following tolerations match the taint created by the kubectl taint line above, thus a pod with either toleration would be able to schedule onto node1.
Viewing and finding resources
The following lists some example commands for viewing and finding resources:
•List all services in the namespace:
kubectl get services
•List all pods in all namespaces:
kubectl get pods --all-namespaces
•List all pods in the namespace, with more details:
kubectl get pods -o wide
•List a particular deployment:
kubectl get deployment my-dep
•List all pods in the namespace, including uninitialized ones:
kubectl get pods --include-uninitialized
Updating resources
The following list describes some example commands for updating resources:
•Rolling update “www” containers of “frontend” deployment, updating the image:
kubectl set image deployment/frontend www=image:v2
•Rollback to the previous deployment:
kubectl rollout undo deployment/frontend
•Watch rolling update status of “frontend” deployment until completion:
kubectl rollout status -w deployment/frontend
•Create a service for a replicated nginx, which serves on port 80 and connects to the containers on port 8000:
kubectl expose rc nginx --port=80 --target-port=8000
•Update a single-container pod’s image version (tag) to v4:
kubectl get pod mypod -o yaml | sed 's/(image: myimage):.*$/1:v4/' | kubectl replace -f
Scaling resources
The following lists some example commands for scaling resources:
•Scale a replicaset named ‘foo’ to 3:
kubectl scale --replicas=3 rs/foo
•Scale a resource specified in “foo.yaml” to 3:
kubectl scale --replicas=3 -f foo.yaml
•If the deployment named mysql’s current size is 2, scale mysql to 3:
kubectl scale --current-replicas=2 --replicas=3 deployment/mysql
•Scale multiple replication controllers:
kubectl scale --replicas=5 rc/foo rc/bar rc/baz
Interacting with running pods
The following lists some example commands for scaling resources:
•Dump pod logs (stdout):
kubectl logs my-pod
•Dump pod logs (stdout) for a previous instantiation of a container:
kubectl logs my-pod --previous
•Dump pod container logs (stdout, multi-container case):
kubectl logs my-pod -c my-container
•Dump pod container logs (stdout, multi-container case) for a previous instantiation of a container:
kubectl logs my-pod -c my-container --previous
•Stream pod logs (stdout):
kubectl logs -f my-pod
•Stream pod container logs (stdout, multi-container case):
kubectl logs -f my-pod -c my-container
•Run pod as interactive shell:
kubectl run -i --tty busybox --image=busybox -- sh
•Attach to a running container:
kubectl attach my-pod -i
•Listen on port 5000 on the local machine and forward to port 6000 on my-pod:
kubectl port-forward my-pod 5000:6000
•Run command in an existing pod (1 container case):
kubectl exec my-pod -- ls /
•Run command in an existing pod (multi-container case):
kubectl exec my-pod -c my-container -- ls /
•Show metrics for a given pod and its containers:
kubectl top pod POD_NAME --containers
Additional kubectl commands
For a full list of supported kubectl commands see https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands
 
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.188.131.255