-
master上的etcd,kube-apiserver,kube-controller-manager kube-scheduler
-
etcd作为kubernetes集群的主数据库,在安装kubernetes各服务之前需要首先安装和启动
-
kube-apiserver服务:提供kubernetes各类资源对象的增,删,改,查及watch等HTTPRest接口,成为集群内各个功能模块之间数据交互和通信的中心枢纽,是整个系统的数据总线和数据中心。提供了资源对象的唯一操作入口,其他所有组件都必须通过它提供的API来操作资源数据
还提供特殊rest接口-kubernetes proxy API接口,把收到rest请求转发到某个node上的kubelet守护进程的rest端口上,由该kubelet进程负责响应
proxy API里关于Node的相关接口,该接口的rest路径为
/api/v1/proxy/nodes/{name}/pods/
如果想要访问pod里某个容器提供的服务
/api/v1/proxy/namespaces/{namespace}/pod/{name}/{path:*}
kubernetes集群之外访问某个pod服务时,可以用proxy API实现,这种场景用于管理目的
-
查看api版本信息:curl localhost:8080/api/v1
-
kube-controller-manager服务:负责执行各种控制器,主要有:endpoint-controller:定期关联service和pod(关联信息由endpoint对象维护),保证service到pod的映射总是最新的。负责集群内的node,pod副本,服务端点,命名空间,服务账号(serviceaccount),资源定额管理。
replication-controller:定期关联replicationController和pod,保证replicationController定义的复制数量与实际运行pod的数量总是一致的。
-
kube-scheduler服务:负责调度pod
-
kube-scheduler以及kube-controller-manager高可用则是在两台master配置文件设置leader-elect参数,kube-scheduer和kube-controller-manager使用一主多从的高可用方案,依赖Etcd实现scheduler和controller-manager的选主功能,
-
-
node上的kubelet,kube-proxy服务
-
kubelet服务:负责Pod对应的容器的创建,启停,与Master密切协作,实现集群管理的基本功能ubelet是Master API Server和Minion之间的桥梁,接收Master API Server分配给它的commands和work,与持久性键值存储etcd、file、server和http进行交互,读取配置信息。
-
kube-proxy服务:Kube-proxy是一个简单的网络代理和负载均衡器,它的作用主要是负责Service的实现,将某个service的访问请求转发到后端的多个pod实例上。在运行过程中会动态创建于service相关的iptables规则,这些规则实现了将访问服务的请求转发到后端pod。
-
-
Kube-dns介绍
Kube-dns用来为kubernetes service分配子域名,在集群中可以通过名称访问service;通常kube-dns会为service赋予一个名为“service名称.namespace.svc.cluster.local”的A记录,用来解析service的clusterip。
-
Kubedns
- 接入SkyDNS,为dnsmasq提供查询服务。
- 替换etcd容器,使用树形结构在内存中保存DNS记录。
- 通过K8S API监视Service资源变化并更新DNS记录。
- 服务10053端口。
-
Dnsmasq
- Dnsmasq是一款小巧的DNS配置工具。
- 在kube-dns插件中的作用是:
- Dockerfile在GitHub上Kubernetes组织的contrib仓库中,位于dnsmasq目录下。
- 在kube-dns插件的编排文件中可以看到,dnsmasq通过参数–server=127.0.0.1:10053指定upstream为kubedns。
-
1通过kubedns容器获取DNS规则,在集群中提供DNS查询服务
2提供DNS缓存,提高查询性能
3降低kubedns容器的压力、提高稳定性
-
kube-dns默认是根据服务名解析域名对应ip
-
如果想要根据pod hostname 解析对应ip,构建service的时候,将clusterIP设置为None(headless service)
-
-
PV PVC,storageclass详解(pv和pvc绑定通过label决定或者storageClassName)
-
PV
是对底层网络共享存储的抽象,将共享存储定义为一种资源,比如node是容器应用消费的资源,包括存储能力,访问模式,存储类型,回收策略,后端存储类型等关键信息的设置。
pv定义资源容量是多少,pvc定义pod使用多少容量
kubectl get pv 显示可用pv的容量多少。
存储能力:存储设备具备的能力,现在支持存储空间的设置(storage=xx)
访问模式:对pv进行访问模式的设置,rwo,单个node挂载
存储类别:pv可以设定其存储的类别(class),通过storageclassname参数指定一个storageclass资源对象的名称。具有特定类别的pv只能与请求该类别的pvc进行绑定,未设定类别的pv则只能对不请求任何类别的pvc绑定。
回收策略:1.保留(retain)2回收空间(recycle)简单清除文件的操作 3删除(delete)
kubernetes 支持的pv类型如下和PV的挂载参数
将PV挂载到一个node上时,根据后端存储的特点,可能需要设置额外的挂载参数,目前可以通过在PV的定义中,设置一个名为volume.beta.kubernetes.io/mount-options: "discard"的annotations来实现,
apiVersion: v1 kind: PersistentVolume metadata: name: rancher-pv labels: pv: rancher-pv spec: capacity: storage: 1Gi volumeMode: Filesystem accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Recycle rbd: monitors: - 10.10.30.30:6789,10.10.30.31:6789,10.10.30.32:6789 pool: zhaoqi #首先要创建好镜像,用rbd create zhao-test --size 1024 image: zhao-test user: admin secretRef: name: ceph-rancher fsType: xfs readOnly: false
pv生命周期的各个阶段(phase)
Available:可用状态,还未与某个pvc绑定
Bound:已于某个pvc绑定
Released:绑定的pvc已经删除资源已释放,但没有被集群回收
Failed:自动资源回收失败
-
PVC
用户对于存储资源的一个申请,就想pod消费node的资源一样,pvc消费pv资源,pvc可以申请特定的存储空间和访问模式
PVC的yaml文件用法
申请8Gi存储空间,访问模式为readwriteonce,pv选择条件为包含标签 release=stable并且包含条件为environment,存储类别为slow(系统中已经存在名为slow的storageclass)
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: rancher-pvc namespace: rancher spec: accessModes: - ReadWriteOnce storageClassName: rancher-sc resources: requests: storage: 10Gi
资源供应:
静态模式:集群管理员手工创建许多pv,在定义pv时需要将后端存储的特性进行设置
动态模式:集群管理员无须手工创建pv,通过storageclass的设置对后端存进行描述,标记为某种类型(class),此时要求pvc对存储的类型进行声明,系统将自动完成pv的创建及与pvc的绑定
资源使用: pod使用volume的定义,将pvc挂载到容器内的某个路径进行使用,volume的类型为pvc,多个pod可以挂载同一个pvc。一旦用户删除了pvc,与之绑定的pv将根据其默认的回收策略delete也会被删除,如果需要保留pv(用户数据),则在动态绑定成功后,用户将系统自动生成pv的回收策略从delete改成retain。
资源绑定:pv一旦绑定到某个pvc上,就被这个pvc独占,不能再与其他pvc进行绑定。然后用户的应用就可以使用这个pvc了,当pvc申请的存储空间比pv的少时,整个pv的空间都能够为pvc所用,可能造成资源的浪费。如果资源供应使用的是动态模式,则系统在为pvc找到合适的storageclass后,将自动创建一个pv并完成与pvc的绑定
-
storageclass
作为对存储资源的抽象定义,标记存储资源的特性和性能,自动完成pv的创建和绑定,实现了动态资源供应
主要包括名称,后端存储的提供者和后端存储的相关参数配置,storageclass一旦被创建出来,将无法修改,如需更改,则只能删除原storageclass的定义重建。
资源提供者(provisioner):描述存储资源的提供者,也可以看作后端存储驱动
参数(parameters):后端存储资源提供者的参数设置,不同的provision包括不同的参数设置,某些参数可以不显示设定
设置默认storageclass 2种方式
-
第一种
首先要开启#kube-apiserver命令行参数--admission-controller=...,DefaultStorageClass
-
第二种
在yaml文件添加
annotations:
storageclass.beta.kubernetes.io/is-default-class="true"
使用命令行
kubectl patch storageclass ceph-rbd -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: rancher-sc #在kube-apiserver命令行参数--admission-controller=...,DefaultStorageClass annotation: storageclass.beta.kubernetes.io/is-default-class: "true" provisioner: kubernetes.io/rbd parameters: monitors: 10.10.30.30:6789,10.10.30.31:6789,10.10.30.32:6789 #adminId | userId 这里需要指定两种 Ceph 角色 admin 和其他 user,admin 角色默认已经有了,其他 user 可以去 Ceph 集群创建一个并赋对应权限值,如果不创建,也可以都指定为 admin adminId: admin #adminSecretName 为上边创建的 Ceph 管理员 admin 使用的 ceph-rancher adminSecretName: ceph-rancher #adminSecretNamespace 管理员 secret 使用的命名空间,默认 default,如果修改为其他的话,需要修改 secret.yaml 增加 namespace: other-namespace adminSecretNamespace: kube-system pool: zhaoqi userId: admin #与adminId相同就行 #需要在rancher 这个ns下创建ceph-rancher这个密钥,否则无法pod使用pvc时,出现密钥问题 userSecretName: ceph-rancher #使用userId映射Ceph RBD图像,与pvc在同一个ns下,与adminsecretName相同就行 fsType: ext4 imageFormat: "2" imageFeatures: "layering"
-
创建一个sc
-
-
StatefulSet
StatefulSet里的每个pod都有稳定,唯一的网络标识,可以用来发现集群内的其他成员,假设
StatefulSet的名字叫kafka,那么第一个pod叫kafka-0,第二个叫kafka-1
StatefulSet控制的Pod副本的启停顺序是受控的,操作第n个pod时,前n-1个pod已经运行且准备好的状态
StatefulSet里的pod采用稳定的持久化 存储卷,通过pv/pvc来实现,删除pod时默认不会删除与StatefulSet相关的存储卷
-
job 启动一个批处理任务,也是管理pod的自动控制器
job所控制的pod是短暂的,可以看做一组docker容器,每个容器仅运行一次,当job控制的所有pod运行结束时,对应的job也就结束了。
-
HPA(pod横向自动扩容,与RC,deployment一样)
通过追踪分析RC控制的所有目标pod的负载变化情况,来确定是否需要针对性地调整目标pod的副本数,通过定期查询pod的资源利用率(cpu)来调整pod的数目。
-
Volume(存储卷)
volume是pod中能够被多个容器访问的共享目录,k8s volume与docker的volume类似,但不能等价。首先k8s的volume定义在pod上,然后供pod里的容器去挂载到具体的文件目录下(相当于定义存储卷,而docker是定义挂载点),其次,k8s中的volume与pod的生命周期相同,但与容器生命周期不同,当容器终止或者重启时,volume中的数据也不会丢失。
-
ConfigMap(初始化所用到的东西-脚本,所要)
以一个或多个key:value的形式保存在k8s系统中供应用使用,既可以用于表示一个变量的值(app=info),也可以用于表示一个完整配置文件的内容(server.xml=<?xml...>...)
生成为容器内的环境变量
设置容器启动命令的启动参数(需设置为环境变量)
以Volume挂载的方式将configmap中的内容挂载为容器内部的文件或目录
configmap注意点 subpath,items
(k8s configMap 中 subPath 字段和 items 字段 - 拾月凄辰 - 博客园)
subpath 将文件挂载到某个目录,但希望只是挂载该文件,不要影响挂载目录下的其他文件。同时将一个volume下的多个目录,挂载到不同的挂载点上。
-
从文件创建
kubectl create configmap cs(名字) --from-file=server.xml
-
从目录创建
kubectl create configmap cmdir --from-file=configfiles
-
使用--from-literal参数进行创建
kubectl create configmap csenv --from-literal=loglevel=info --from-literal=appdatadir=/var/data
-
通过volume方式使用ConfigMap
-
-
NodeSelector 定向调度
-
taints和tolerations(污点和容忍)
在node上设置一个或多个taint之后,除非pod明确声明能够容忍这些污点(taints),否则无法再这些node上运行,toleration是pod的属性,让pod能够运行在标注taint的node上。
kubectl taint nodes times03 key=value:NoSchedule(除非pod容忍这个taint,否则不会调度到times03)
-
DaemonSet:在每个Node上调度一个pod
主要用于日志采集(fluentd),性能监控程序(例如calico)
-
service
要解决pod地址可变的问题,由于pod随时可能故障,并可能在其他节点上被重启,用一个service代表提供某一类功能(通过标签来筛选)的一些pod,并分配不随pod位置变化而改变的虚拟访问地址(cluster ip),这个地址并不绑定到任何借口,将作为访问服务的抽象地址,访问该地址会被映射到pod的实际地址,实际上通过kube-proxy进程,负责将到某个service的访问给代理或者负载均衡到具体的pod上。
-
3种工作模式 userspace,iptables,ipvs 现在使用后2种
-
有2种方法可以用于暴露服务
-
service的VIP:也就是cluster IP
-
service的DNS: 服务名.命名空间.svc.cluster.local这条DNS记录访问
-
关系是这样service -> endpoints -> pods
-
service比较重要的一个点sessionAffinity 绑定同一个客户端ip到同一个pod上
sessionAffinity: ClientIP
-
-
-
proxy API 代理
kubernetes proxy API也有service的proxy接口,用法用pod差不多,就是把pods换成services
-
容器健康检查
-
livenessProbe
livenessProbe: exec: command: - cat - /tmp/health initialDelaySeconds: 15 timeoutSeconds: 1 如果该命令返回值为0,则表明容器处于健康状态,否则表明容器处于不健康状态 实现容器的http检查,kubelet发送一个http请求到本地主机和端口及指定的路径,检查容器的健康状况
-
readinessProve
readinessProve: failureThreshold: 8 httpGet: host: 127.0.0.1 path: /healthz port: 6443 scheme: HTTPS initialDelaySeconds: 15 timeoutSeconds: 15
-
-
service account
一个service account对象里面可以包括多个不同的secret对象,secret从属于service account资源对象,属于service account的一部分。一个secret由ns,token,ca组成
查看系统中service account对象(服务账户),看到一个名为default的service account对象
包含一个名为 default-token-4rkqn的secret,这个secret同时是mountable secrets,表明他是需要被mount到pod上的
查看 default-token-4rkqn的tokens内容,也就是查看secret的内容
每个namespaces下有一个名为default的默认的service account对象,而名为tokens的当做volume被mount到pod里的secret,当pod启动时,这个secret会自动被mount到pod的指定目录下,用来协助完成pod中的进程访问API Server时的身份鉴权过程。
secret:用API Server私钥创建一个token,并用该token,CA证书及namespace名称等3个信息产生一个新的secret对象。然后放入刚才的service account中,
每个ns下有一个名为default的默认的service account对象,这个service account里面有一个名为tokens的可以当作volume一样被mount到pod里的secret,当pod启动时,这个secret会自动被mount到pod的指定目录下,用来协助完成pod中的进程访问api server时的身份鉴权过程
-
secret私密凭据
secret 3种类型
docker-registry:专门为下拉镜像用的
tls: 配置证书和私钥
generic: 通用secret
主要作用是保管私密数据,比如密码,oauth tokens,ssh keys等信息。
data域的各子域的值必须为base64编码值,一旦secret被创建,通过3种方式使用它
(1)创建pod是,通过为pod指定service account来自动使用该secret
(2)通过挂载该secret到pod来使用它
(3)docker镜像下载时使用,通过指定pod的spc.imagepullsecrets来引用它
-
第一种
kubectl create secret generic ceph-rancher --type="ceph.com/rbd" --from-literal=key='AQBuH9pcH8ClGBAALMHLYr5k0pbT2gbRlWdodw==' --namespace=kube-system
-
第二种,如何将secret通过挂载的方式添加到pod的vulume中
apiVersion: v1 kind: Secret metadata: name: ceph-rancher namespace: kube-system type: "ceph.com/rbd" data: #ceph base64转换后的key key: QVFCdUg5cGNIOENsR0JBQUxNSExZcjVrMHBiVDJnYlJsV2RvZHc9PQo=
secret保管其他系统的敏感信息(数据库的用户名和密码),并以mount的方式将secret挂载到Container中,然后通过访问容器目录中的文件的方式获取敏感信息,一旦这个pod被调度,则kubelet将试着获取secret的值。一旦secret被pod获取,则kubelet将创建并mount包含secret的volume。只有所有volume被mount后,pod中的Container才会被启动
-
ingress策略:在service 之前加了一层ingress
Ingress 的实现分为两个部分 Ingress Controller 和 Ingress
Ingress Controller 是流量的入口,是一个实体软件, 一般是Nginx 和 Haproxy
Ingress 描述具体的路由规则
简单说: Ingress 描述路由规则, Ingress Controller 实时实现规则
Ingress Contronler 通过与 Kubernetes API 交互,动态的去感知集群中 Ingress 规则变化,然后读取它,按照自定义的规则,规则就是写明了哪个域名对应哪个service,生成一段 Nginx 配置,再写到 Nginx-ingress-control的 Pod 里,这个 Ingress Contronler 的pod里面运行着一个nginx服务,控制器会把生成的nginx配置写入/etc/nginx.conf文件中,然后 reload 一下 使用配置生效。以此来达到域名分配置及动态更新的问题。
-
转发到单个后端服务上
因为转发到后端的唯一service上,无需定义rule,对ingress controller的访问请求都将被转发到myweb:8080这个服务上
-
同一域名下,不同的URL路径被转发到不同的服务上
对mywebsite.com/web的访问请求将被转发到web-service:80服务上
对mywebsite.com/api的访问请求将被转发到apiservice:80801服务上
-
不同的域名被转发到不同的服务上
一个网址通过不同的域名或虚拟主机名提供不同的服务的场景,foo.bar.com域名由service1提供服务,bar.foo.com域名由service2提供服务
-
不使用域名的转发规则
网站不使用域名直接提供服务的场景,通过任意一台运行ingress-controller的node都能访问到后端的服务。(访问方式 ingress-controller-ip/demo请求转发到webapp:8080/demo)使用无域名的ingress转发规则时,将默认禁用非安全HTTP,强制开启HTTPS。
-
-