资源类型
自主式pod
- 这种Pod本身是不能自我修复的,当Pod被创建后(不论是由你直接创建还是被其他Controller),都会被Kuberentes调度到集群的Node上。直到Pod的进程终止、被删掉、因为缺少资源而被驱逐、或者Node故障之前这个Pod都会一直保持在那个Node上。Pod不会自愈。如果Pod运行的Node故障,或者是调度器本身故障,这个Pod就会被删除。同样的,如果Pod所在Node缺少资源或者Pod处于维护状态,Pod也会被驱逐。
控制器管理pod
- Kubernetes使用更高级的称为Controller的抽象层,来管理Pod实例。Controller可以创建和管理多个Pod,提供副本管理、滚动升级和集群级别的自愈能力。例如,如果一个Node故障,Controller就能自动将该节点上的Pod调度到其他健康的Node上。虽然可以直接使用Pod,但是在Kubernetes中通常是使用Controller来管理Pod的。
资源控制器分类
- ReplicaSet
- 确保容器应用的副本数保持在用户定义的副本数
- 不支持rolling update,建议使用deployment
- Deployment
- StatefulSet
- 有状态服务
- 稳定的网络标志,即pod重新调度后podname和hostname 不变,headless service实现(没有cluster ip的service)
- 稳定的持久化存储,重新调度后还是能访问相同的数据卷。
- 有序部署,有序扩展,有序回收,即从0 - n-1在下一个pod运行之前所有之前的pod都是running和Ready状态。
- DaemonSet
- 确保全部node(或一些node)运行一个pod副本,当有node加入集群时也会为他们新增一个pod,当有node从集群中移除时,这些也会被回收。
- Job
- 负责批处理任务,保证批处理的一个或多个pod成功结束。
- Cronjob
- 管理基于时间的job,给定时间内只运行一次,周期性的在指定时间内运行。
- HPA
- Horizontal Pod Autoscaling可以根据CPU利用率自动伸缩一个Replication Controller、Deployment 或者Replica Set中的Pod数量。
资源控制器会通过matchLabels对象,管理标签名为backend-acount的模版。pod是由template对象生成的,所以pod的标签继承template的标签为backend-account,通过kubectl get pod –show lables 查看。
如果手动修改其中一个pod的标签名使其不等于backend-account,则资源管理会失去对这个pod的管理权限,从而根据replicas生成新的标签为backend-acount的pod。删除控制也不会影响到修改标签后的的pod.
spec:
replicas: 0
selector:
matchLabels:
name: backend-account
strategy:
rollingUpdate:
maxSurge: 1
maxUnavailable: 25%
type: RollingUpdate
template:
metadata:
labels:
name: backend-account
扩容命令:
kubectl scale deployment <控制器名字> --replicas=3
更新镜像
kubectl set image deploy backend-account backend-account=nginx:1.9.1
更新所有镜像
kubectl set image deploy *=nginx:1.9.1 --all
回滚
kubectl rollout undo deploy
从本地文件更新镜像
kubectl set image -f path/to/file.yaml nginx=nginx:1.9.1 --local -o yaml
Deployment控制器更新策略
strategy:
rollingUpdate:
maxSurge: 1
maxUnavailable: 25%
type: RollingUpdate
- maxSurge:
- 升级过程中最多可以比原先设置多出的POD数量
- 例如:maxSurage=1,replicas=5,则表示Kubernetes会先启动1一个新的Pod后才删掉一个旧的POD,整个升级过程中最多会有5+1个POD。
- maxUnavaible:
- 升级过程中最多有多少个POD处于无法提供服务的状态
查看历史更新版本
kubectl rollout history deploy backend-account
只有apply 服务时后面加–record 才能看到历史
service类型
- clusterIP 自动分配一个仅cluster内部访问的IP
- Headless Servcie 有时候不需要或不想负载均衡,以及一个单独的serviceIP,可以设置ClusterIP值为None,来创建服务,这类服务kube-proxy不会处理。
- 我们可以通过serviceName.default.svc.cluster.local访问后端pod.此域名会被内部dns解析成多个A记录,对应后端多个pod. statefulset情况可以通过
- serviceName.default.svc.cluster.local/num 访问对应pod, num为整数。num为0访问statefulset-0.
- NodePort 在clusterIP基础上为service在节点上绑定一个端口,这样可以通过NodeIP:NodePort 形式访问。
- Loadbalancer 在nodePort的基础上,借助一个cloud Provider 创建一个外部的负载均衡器,将请求转发到NodePort.
- ExternalName 当ServiceType被配置为这种方式时,该服务的目的就不是为了外部访问了,而是为了方便集群内部访问外部资源。举个例子,假如目前集群的pod要访问一组DB资源,而DB是部署在集群外部的物,理机,还没有容器化,可以配置这么一个服务
apiVersion: v1
kind: Service
metadata:
name: dbserver
namespace: default
spec:
type: ExternalName
externalName: database.abc.com
service原理
用户通过kubectl命令向apiserver创建service命令,apiserver接收到请求后将数据转存到etcd.每个节点都有kube-proxy 负责感知service pod变化,变化信息导入到iptables. iptables使用nat等技术将虚拟ip的流量转至endpoint.
ConfigMap
我们可以使用kubectl create configmap 命令创建configmaps 从目录,文件,循环值。
从目录创建
# Create the local directory
mkdir -p configure-pod-container/configmap/
# Download the sample files into `configure-pod-container/configmap/` directory
wget https://kubernetes.io/examples/configmap/game.properties -O configure-pod-container/configmap/game.properties
wget https://kubernetes.io/examples/configmap/ui.properties -O configure-pod-container/configmap/ui.properties
# Create the configmap
kubectl create configmap game-config --from-file=configure-pod-container/configmap/
$ kubectl describe configmaps game-config
Name: game-config
Namespace: default
Labels: <none>
Annotations: <none>
Data
====
game.properties:
----
enemies=aliens
lives=3
enemies.cheat=true
enemies.cheat.level=noGoodRotten
secret.code.passphrase=UUDDLRLRBABAS
secret.code.allowed=true
secret.code.lives=30
ui.properties:
----
color.good=purple
color.bad=yellow
allow.textmode=true
how.nice.to.look=fairlyNice
Events: <none>
文件名game.properties是key, value是文件内容。
从文件创建
kubectl create configmap game-config-2 --from-file=configure-pod-container/configmap/game.properties
从命令行参数获取值创建
kubectl create configmap special-config --from-literal=special.how=very --from-literal=special.type=charm
pod中使用configmap
pods/pod-single-configmap-env-variable.yaml
apiVersion: v1
kind: Pod
metadata:
name: dapi-test-pod
spec:
containers:
- name: test-container
image: k8s.gcr.io/busybox
command: [ "/bin/sh", "-c", "env" ]
env:
# Define the environment variable
- name: SPECIAL_LEVEL_KEY
valueFrom:
configMapKeyRef:
# The ConfigMap containing the value you want to assign to SPECIAL_LEVEL_KEY
name: special-config
# Specify the key associated with the value
key: special.how
restartPolicy: Never
创建configmap 包含多个key value
configmap/configmap-multikeys.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: special-config
namespace: default
data:
SPECIAL_LEVEL: very
SPECIAL_TYPE: charm
pods/pod-configmap-envFrom.yaml
apiVersion: v1
kind: Pod
metadata:
name: dapi-test-pod
spec:
containers:
- name: test-container
image: k8s.gcr.io/busybox
command: [ "/bin/sh", "-c", "env" ]
envFrom:
- configMapRef:
name: special-config
restartPolicy: Never
将configmap数据填入数据卷
pods/pod-configmap-volume.yaml
apiVersion: v1
kind: Pod
metadata:
name: dapi-test-pod
spec:
containers:
- name: test-container
image: k8s.gcr.io/busybox
command: [ "/bin/sh", "-c", "ls /etc/config/" ]
volumeMounts:
- name: config-volume
mountPath: /etc/config
volumes:
- name: config-volume
configMap:
# Provide the name of the ConfigMap containing the files you want
# to add to the container
name: special-config
restartPolicy: Never
/etc/config下会生成两个文件,文件名是special-confg的key SPECIAL_LEVEL 和SPECIAL_TYPE, 内容为value值
ConfigMap 热更新
更新configmap后
- 使用该configmap挂载env不会同步更新
- 使用该configmap挂载的volume需要一段时间(10秒左右)才能同步更新。
文档信息
- 本文作者:Beast
- 本文链接:https://beastpu.github.io/2019/03/04/k8s-%E8%B5%84%E6%BA%90/
- 版权声明:自由转载-非商用-非衍生-保持署名(创意共享3.0许可证)