A model for thinking about Kubernetes security in the context of Cloud Native security.

In Kubernetes, scheduling refers to making sure that Pods are matched to Nodes so that Kubelet can run them. Scheduling overview A scheduler watches for newly created Pods that have no Node assigned. For every Pod that the scheduler discovers, the scheduler becomes responsible for finding the best Node for that Pod to run on. The scheduler reaches this placement decision taking into account the scheduling principles described below.

In the scheduling-plugin NodeResourcesFit of kube-scheduler, there are two scoring strategies that support the bin packing of resources: MostAllocated and RequestedToCapacityRatio. Enabling bin packing using MostAllocated strategy The MostAllocated strategy scores the nodes based on the utilization of resources, favoring the ones with higher allocation. For each resource type, you can set a weight to modify its influence in the node score. To set the MostAllocated strategy for the NodeResourcesFit plugin, use a scheduler configuration similar to the following:

Application logs can help you understand what is happening inside your application. The logs are particularly useful for debugging problems and monitoring cluster activity. Most modern applications have some kind of logging mechanism. Likewise, container engines are designed to support logging. The easiest and most adopted logging method for containerized applications is writing to standard output and standard error streams. However, the native functionality provided by a container engine or runtime is usually not enough for a complete logging solution.

This page outlines steps to find out what container runtime the nodes in your cluster use. Depending on the way you run your cluster, the container runtime for the nodes may have been pre-configured or you need to configure it. If you're using a managed Kubernetes service, there might be vendor-specific ways to check what container runtime is configured for the nodes. The method described on this page should work whenever the execution of kubectl is allowed.

kube-state-metrics, an add-on agent to generate and expose cluster-level metrics.

Synopsis Copy files and directories to and from containers. kubectl cp <file-spec-src> <file-spec-dest> Examples # !!!Important Note!!! # Requires that the 'tar' binary is present in your container # image. If 'tar' is not present, 'kubectl cp' will fail. # # For advanced use cases, such as symlinks, wildcard expansion or # file mode preservation, consider using 'kubectl exec'. # Copy /tmp/foo local file to /tmp/bar in a remote pod in namespace <some-namespace> tar cf - /tmp/foo | kubectl exec -i -n <some-namespace> <some-pod> -- tar xf - -C /tmp/bar # Copy /tmp/foo from a remote pod to /tmp/bar locally kubectl exec -n <some-namespace> <some-pod> -- tar cf - /tmp/foo | tar xf - -C /tmp/bar # Copy /tmp/foo_dir local directory to /tmp/bar_dir in a remote pod in the default namespace kubectl cp /tmp/foo_dir <some-pod>:/tmp/bar_dir # Copy /tmp/foo local file to /tmp/bar in a remote pod in a specific container kubectl cp /tmp/foo <some-pod>:/tmp/bar -c <specific-container> # Copy /tmp/foo local file to /tmp/bar in a remote pod in namespace <some-namespace> kubectl cp /tmp/foo <some-namespace>/<some-pod>:/tmp/bar # Copy /tmp/foo from a remote pod to /tmp/bar locally kubectl cp <some-namespace>/<some-pod>:/tmp/foo /tmp/bar Options -c, --container string Container name.

Synopsis Renames a context from the kubeconfig file. CONTEXT_NAME is the context name that you want to change. NEW_NAME is the new name you want to set. Note: If the context being renamed is the 'current-context', this field will also be updated. kubectl config rename-context CONTEXT_NAME NEW_NAME Examples # Rename the context 'old-name' to 'new-name' in your kubeconfig file kubectl config rename-context old-name new-name Options -h, --help help for rename-context

Synopsis Mark node as unschedulable. kubectl cordon NODE Examples # Mark node "foo" as unschedulable kubectl cordon foo Options --dry-run string[="unchanged"]     Default: "none" Must be "none", "server", or "client". If client strategy, only print the object that would be sent, without sending it. If server strategy, submit server-side request without persisting the resource. -h, --help help for cordon -l, --selector string Selector (label query) to filter on, supports '=', '==', and '!

Synopsis Create a resource from a file or from stdin. JSON and YAML formats are accepted. kubectl create -f FILENAME Examples # Create a pod using the data in pod.json kubectl create -f ./pod.json # Create a pod based on the JSON passed into stdin cat pod.json | kubectl create -f - # Edit the data in registry.yaml in JSON then create the resource using the edited data kubectl create -f registry.