volume
k8s通过数据卷来提供pod数据的持久化,k8s的数据卷是对docker数据卷的扩展,k8s的数据卷是pod级别的,用来实现pod中容器的文件共享
volume是pod中能被多个容器访问的共享目录,k8s中的volume与pod生命周期相同,当容器终止或重启时,volume中的数据不会丢失。
示例
apiVersion: extensions/v1beta1 kind: Deployment metadata: name: frontend spec: replicas: 1 selector: matchLabels: tier: frontend matchExpressions: - {key: tier,operator: In,values: [frontend]} template: metadata: labels: app: app-demo tier: frontend spec: volumes: - name: datavo1 emptyDir: {} containers: - name: tomcat-demo image: consol/tomcat-7.0 imagePullPolicy: IfNotPresent volumeMounts: - mountPath: /mydata-data #将emptydir挂在到/mydata-data目录 name: datavo1 ports: - containerPort: 8080
本地数据卷
emptyDir:
empytDir volume是在pod分配到node的时创建的,初始内容为空,并且无需指定主机上对应的目录文件(k8s自动分配),只要pod存在,emptydir数据卷都会存在(容器删除不会导致emptydir数据卷丢失),当pod从node上移除时,emptyDir中的数据也会被永久删除
hostPath:
hostPath为在pod上挂载容器宿主机上的文件或目录,如果pod需要使用宿主机的某些文件,可以使用HostPath
创建一个pod需要使用宿主机的ssl证书,将宿主机的/etc/ssl/certs目录挂载到容器,示例如下
apiVersion: v1 kind: Pod metadata: name: nginx spec: containers: - name: nginx image: nginx ports: - containerPort: protocol: TCP volumeMounts: - name: ssl-certs mountPath: /etc/ssl/certs readOnly: true volumes: - name: ssl-certs hostPath: path: /etc/ssl/certs
网络数据卷
NFS:
使用nfs网路文件系统存储数据(通过tcp/ip访问资源),需要部署一个nfs server,如下:
示例
apiVersion: v1 kind: Pod metadata: name: nfs-web spec: containers: - name: web image: nginx ports: - name: web containerPort: volumeMounts: - name: nfs mountPath: "/usr/share/nginx/html" volumes: - name: nfs nfs: server: nfs.server.default.kube.local #nfs的server地址 path: "/" #nfs的共享目录
ISCSI
apiVersion: v1 kind: Pod metadata: name: iscsipd spec: containers: - name: iscsipd-ro image: kubernetes/pause volumeMounts: - name: iscsi-ro mountPath: "/mnt/iscsipd" - name: iscsipd-rw image: kubernetes/pause volumeMounts: - name: iscsi-rw mountPath: "/mnt/iscsipd" volumes: - iscsi: fsType: ext4 #文件系统类型 iqn: iqn.2001-04/com.example:storage.kube.sys1.xyz #iscis的iqn号 lun: 0 #iscis的逻辑单元号 readOnly: true targetPortal: 10.10.10.10:3260 #iscsiTarget服务地址 name: iscsipd-ro - iscsi: fsType: ext4 iqn: iqn.2001-04/com.example:storage.kube.sys1.xyz lun: 1 readOnly: true targetPortal: 10.10.10.10:3260 name: iscsipd-rw
PV(Persistent Volume) 网络存储:
信息数据卷 secret
Git Repo
kubernetes支持将git Repo下载到pod中,目前通过Git Repo数据卷实现,即当配置Git Repo数据卷时,就下载配置的Git仓库到Pod的数据卷中,然后挂载到容器
[root@k8s_master ~]# cat gitrepo.yaml apiVersion: v1 kind: Pod metadata: name: busybox namespace: default labels: app: busybox spec: containers: - name: busybox image: busybox command: - "sleep" - "3600" volumeMounts: - mountPath: /data name: busybox-config volumes: - name: busybox-config gitRepo: repository: http://username:password@10.10.10.217/root/flagship.git revision: master
Namespace命名空间
Namespce在很多情况下实现了多租户的资源隔离,通过将集群内部的资源对象分配到不同的namespace中,形成逻辑上分组的不同项目、小组或用户组,便于区分管理
k8s启动后,默认创建一个名为“default”的namespace,通过kubectl命令可查看,用户创建的资源对象,默认放到default命名空间中
kubectl get namespaces #获取命名空间 kubectl get pods(service、rc ) --namespace=<namespace名称> #获取指定命名空间的资源
Annotation
Annotation与label类似,也是用key=value键值对的形式进行定义,不同的是,lable有严格的命名规则,定义的对象为元数据(metadata)并且用于label selector,而Annotation 是用户定义的任意附加信息
- build信息、release信息、docker镜像信息。如时间戳、release id号,docker registry地址
- 日志库、监控库、分析库等资源库地址
- 程序调试工具信息
- 团队联系信息
准入控制器(Admission Controller)
准入控制器(Admission Controller)位于 API Server 中,在对象被持久化之前,准入控制器拦截对 API Server 的请求,一般用来做身份验证和授权。其中包含两个特殊的控制器:MutatingAdmissionWebhook
和 ValidatingAdmissionWebhook
。分别作为配置的变异和验证准入控制 webhook。
- 变更(Mutating)准入控制:修改请求的对象
- 验证(Validating)准入控制:验证请求的对象
准入控制器是在 API Server 的启动参数重配置的。一个准入控制器可能属于以上两者中的一种,也可能两者都属于。当请求到达 API Server 的时候首先执行变更准入控制,然后再执行验证准入控制。
在部署 Kubernetes 集群的时候都会默认开启一系列准入控制器,如果没有设置这些准入控制器的话可以说你的 Kubernetes 集群就是在裸奔,应该只有集群管理员可以修改集群的准入控制器。
默认开启如下的准入控制器。
--admission-control=ServiceAccount,NamespaceLifecycle,NamespaceExists,LimitRanger,ResourceQuota,MutatingAdmissionWebhook,ValidatingAdmissionWebhook
准入控制器列表
Kubernetes 目前支持的准入控制器有: AlwaysPullImages:此准入控制器修改每个 Pod 的时候都强制重新拉取镜像。 DefaultStorageClass:此准入控制器观察创建PersistentVolumeClaim时不请求任何特定存储类的对象,并自动向其添加默认存储类。这样,用户就不需要关注特殊存储类而获得默认存储类。 DefaultTolerationSeconds:此准入控制器将Pod的容忍时间notready:NoExecute和unreachable:NoExecute 默认设置为5分钟。 DenyEscalatingExec:此准入控制器将拒绝exec 和附加命令到以允许访问宿主机的升级了权限运行的pod。 EventRateLimit (alpha):此准入控制器缓解了 API Server 被事件请求淹没的问题,限制时间速率。 ExtendedResourceToleration:此插件有助于创建具有扩展资源的专用节点。 ImagePolicyWebhook:此准入控制器允许后端判断镜像拉取策略,例如配置镜像仓库的密钥。 Initializers (alpha):Pod初始化的准入控制器,详情请参考动态准入控制。 LimitPodHardAntiAffinityTopology:此准入控制器拒绝任何在 requiredDuringSchedulingRequiredDuringExecution 的 AntiAffinity 字段中定义除了kubernetes.io/hostname 之外的拓扑关键字的 pod 。 LimitRanger:此准入控制器将确保所有资源请求不会超过 namespace 的 LimitRange。 MutatingAdmissionWebhook (1.9版本中为beta):该准入控制器调用与请求匹配的任何变更 webhook。匹配的 webhook是串行调用的;如果需要,每个人都可以修改对象。 NamespaceAutoProvision:此准入控制器检查命名空间资源上的所有传入请求,并检查引用的命名空间是否存在。如果不存在就创建一个命名空间。 NamespaceExists:此许可控制器检查除 Namespace 其自身之外的命名空间资源上的所有请求。如果请求引用的命名空间不存在,则拒绝该请求。 NamespaceLifecycle:此准入控制器强制执行正在终止的命令空间中不能创建新对象,并确保Namespace拒绝不存在的请求。此准入控制器还防止缺失三个系统保留的命名空间default、kube-system、kube-public。 NodeRestriction:该准入控制器限制了 kubelet 可以修改的Node和Pod对象。 OwnerReferencesPermissionEnforcement:此准入控制器保护对metadata.ownerReferences对象的访问,以便只有对该对象具有“删除”权限的用户才能对其进行更改。 PodNodeSelector:此准入控制器通过读取命名空间注释和全局配置来限制可在命名空间内使用的节点选择器。 PodPreset:此准入控制器注入一个pod,其中包含匹配的PodPreset中指定的字段,详细信息见Pod Preset。 PodSecurityPolicy:此准入控制器用于创建和修改pod,并根据请求的安全上下文和可用的Pod安全策略确定是否应该允许它。 PodTolerationRestriction:此准入控制器首先验证容器的容忍度与其命名空间的容忍度之间是否存在冲突,并在存在冲突时拒绝该容器请求。 Priority:此控制器使用priorityClassName字段并填充优先级的整数值。如果未找到优先级,则拒绝Pod。 ResourceQuota:此准入控制器将观察传入请求并确保它不违反命名空间的ResourceQuota对象中列举的任何约束。 SecurityContextDeny:此准入控制器将拒绝任何试图设置某些升级的SecurityContext字段的pod 。 ServiceAccount:此准入控制器实现serviceAccounts的自动化。 用中的存储对象保护:该StorageObjectInUseProtection插件将kubernetes.io/pvc-protection或kubernetes.io/pv-protection终结器添加到新创建的持久卷声明(PVC)或持久卷(PV)。在用户删除PVC或PV的情况下,PVC或PV不会被移除,直到PVC或PV保护控制器从PVC或PV中移除终结器。有关更多详细信息,请参阅使用中的存储对象保护。 ValidatingAdmissionWebhook(1.8版本中为alpha;1.9版本中为beta):该准入控制器调用与请求匹配的任何验证webhook。匹配的webhooks是并行调用的;如果其中任何一个拒绝请求,则请求失败。
对于Kubernetes 1.10及更高版本,建议使用--enable-admission-plugins
标志运行以下一组准入控制器(顺序无关紧要)。
注意: --admission-control
在1.10中已弃用并替换为--enable-admission-plugins
。
--enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota
对于Kubernetes 1.9及更早版本,建议使用--admission-control
标志(顺序有关)运行以下一组许可控制器。