Kubenete study notes (Replication Controller)

Kubenete study notes (Replication Controller)

Replication controller:

ReplicationController schedules pod to one work node, kubelet application in node pulls image and create containers.Pod started by “kubectl run” is not created directly. ReplicationController is created by command and replicationController creates podCreate pod: kubectl run [replication controller name] --image=[image name] --port=[port number] --generator=run/v1. Without --generate flag, it creates deployment instead of replicationControllerReplication controller is able to scale number of pods: kubectl scale rc [replication controller] --replicas=3Replication controller ensures number of pods by label selector matches desired number (replica count), if not, it starts new pod or delete existing pod Pods started by replication controller via kubectl run command can not be deleted, a new pod will be bring up, need to delete replication controller

Defining liveness probe allow

spec: containers: livenessProbe: path: / port: 8080

Spec/containers/livenessProbe/initialDelaySeconds is important to ensure initial start up success before sending first liveness probe request

Troubleshoot pod failure:kubectl describe po [podname] Last state and events can show previous pod problemkubectl logs [pod name] --previous shows log of previous crashed pod

Define good liveness probe:

Use /health endpoint Keep probe lightweight No retry loop in probe is required

Replication controller definition contains pod template:

spec: template: metadata: labels: app: kubia spec: containers: - name: kubia image: luksa/kubia ports: - containerPort: 8080

Don’t specify a pod selector when defining a ReplicationController. Let Kubernetes extract it from the pod template, if replicationController’s label selector does not match pod template, kubernetes api server will report errorChanges to replication controller’s label selector and the pod template have no effect on existing pods.By changing a pod’s labels, it can be removed from or added to the scope of a ReplicationController. It can even be moved from one ReplicationController to another. Pod’s metadata.ownerReferences shows replication controller information

Compare replication set(apiVersion: apps/v1beta2 kind: ReplicaSet) and replication controller:Selector expression under in selector.matchLabels for replication setSupport a rich set of selector expression like ‘IN’, ‘NOT IN’, ‘EXISTS’, ‘DOES NOT EXIST’

DaemonSet: (apiVersion: apps/v1beta2 kind: DaemonSet)Use DaemonSet to start exactly one pod on each nodeUsed for common services like log collector etcAuto adapt to node addition and create podNo replication count required Can specify node-selector to deploy pods to a subset of nodesDeploying pods via daemonset bypasses kubenetes scheduler

JobResource: (apiVersion: batch/v1 kind: Job )Used for run-once adhoc taskSet spec: restartPolicy: OnFailure/Never for handling job execution failureSet spec: completions: 5 (number of execution) parallelism: 2 (number of parallel nodes) to allow multiple times and parallel execution of jobSet spec:activeDeadlineSeconds to terminate long run job. Set spec:backoffLimit for number of retries before marking job as fail

Cronjob: (apiVersion: batch/v1beta1 kind: CronJob)Set spec: schedule: "0,15,30,45 "

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。