MyLinuxOPS

k8s在部署完毕以后一定会复制一个配置文件/etc/kubernetes/admin.conf，此文件中保存了当前API-Server中一个管理员账号的用户名、密码等相关信息。此文件有特定组织格式的文件。 /etc/kubernetes目录下的所有conf文件都有类似的格式，只不过他们都是被k8s上不同的组件所使用的。 12root@k8s-master01:~# ls /etc/kubernetes/admin.conf controller-manager.conf kubelet.conf manifests pki scheduler.conf 这些文件是为了让客户端便于访问API-Server所使用的。 在k8s上认证时，需要使用token或账号密码或证书之类，而每一次使用kubectl去联系API-Server时都需要带上这些信息。 12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849# 使用kubectl options可以看到添加哪些 ...

ServiceAccount资源清单格式1234567891011121314apiVersion: v1 # ServiceAccount所属的API群组及版本kind: ServiceAccount # 资源类型标识metadata: name <string> # 资源名称 namespace <string> # ServiceAccount是名称空间级别的资源automountServiceAccountToken <boolean> # 是否让Pod自动挂载API令牌secrets <[]Object> # 以该SA运行的Pod所要使用的Secret对象组成的列表 apiVersion <string> # 引用的Secret对象所属的API群组及版本，可省略 kind <string> # 引用的资源的类型，这里是指Secret，可省略 name <string> # 引用的Secret对象的名称，通常仅给出该字段即可 namespace <strin ...

认证、授权和准入控制对应的三个单词分别为：Authn、Authz、Admission。 他们分别的作用： Authn：由于系统不是开放给所有用户的，因而必须确保来访问系统的是当前系统注册过且允许其使用该系统资源的用户 Authz：即便能进入同一个场所，不同用户所能够或得的不同资源的操作权限应该不同的。Authz是一个权限管理和分派的功能。 Admission：Admission本意为审计，但在k8s中其实现的功能比审计更为复杂。他们只发挥在用户的写请求上。它能够实现一些更为独特的功能，主要体现在2方面: 校验：用户创建数据时，若用户给定的资源清单中的字段违反了对应资源规范所使用的格式，或赋值违反了其值所应该具有的取值格式，我们应该识别到这种错误，以避免将其存入到API-server中。 变异：允许用户自定义一些允许其去修改一些对应字段值的。 k8s认证授权准入的基本工作逻辑 当K8S用户试图通过API-Server来完成资源操作时，他通常要完成3个步骤： 对用户的身份做验证，看用户的身份是否有合法的访问系统的权限。 对用户请求的动作是否得到确切的授权。如果用户执行的是读操作，那么 ...

statefulset为通用的有状态应用控制器。 每个pod都有自己的唯一标识，故障时，它只能被拥有同一个标识的新实例所取代。 如果有必要，可以为每个pod配置专用的存储卷，且只能是PVC格式。通过pvc模板来为每个pod创建专用PV statefulset配置规范12345678910111213141516171819202122apiVersion: apps/v1 # API群组及版本；kind: StatefulSet # 资源类型的特有标识metadata: name <string> # 资源名称，在作用域中要唯一 namespace <string> # 名称空间；StatefulSet隶属名称空间级别spec: replicas <integer> # 期望的Pod副本数，默认为1 selector <object> # 标签选择器，须匹配Pod模板中的标签，必选字段 template <object> # Pod模板对象，必选字段 revisionHistoryLimit <in ...

Job是执行一次性任务，而CronJob执行周期性作业。 CronJob和Job之间的关系类似于，Deployment和replicaSet之间的关系，CronJob需要借助于Job控制器来完成其功能的。 所以CronJob是通过Job来控制Pod，而非直接控制Pod CronJob资源定义规范123456789101112131415apiVersion: batch/v1beta1 # API群组及版本kind: CronJob # 资源类型特有标识metadata: name <string> # 资源名称，在作用域中要唯一 namespace <string> # 名称空间；CronJob资源隶属名称空间级别spec: jobTemplate <Object> # job作业模板，必选字段 metadata <object> # 模板元数据 spec <object> # 作业的期望状态 schedule <string> # 调度时间设定，必选字段 concurre ...

ReplicaSet，Deployment和DaemonSet这些控制器都是负责始终运行在后台接受客户端请求并响应的服务进程，而有些进程如备份任务、一次性的计算批处理任务，通常需要使用Job控制器来负责管理。 Job的执行流程Job可以分为单队列多次执行和多队列并行执行。Job中的Pod运行完毕后会complated，其不会被重新启动起来。 Job资源定义规范12345678910111213apiVersion: batch/v1 # API群组及版本kind: Job # 资源类型特有标识metadata: name <string> # 资源名称，在作用域中要唯一 namespace <string> # 名称空间；Job资源隶属名称空间级别spec: selector <object> # 标签选择器，必须匹配template字段中Pod模板中的标签 template <object> # Pod模板对象 completions <integer> # 期望的成功完成的作业次数，成功运行结束的Pod ...

DaemonSet控制器是用于保证在集群上精确运行的负载有多少个实例，如有10个节点那么其就会在每个节点上只运行一个。 DaemonSet可以实现在集群内所有节点上只运行一个，也可以在集群内拥有某个标签的节点上运行一个。 DaemonSet可以简称为DS. 12345# 获取当前系统上kube-system名称空间下的ds资源root@k8s-master01:~/yaml/chapter08# kubectl get ds -n kube-systemNAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGEkube-flannel-ds 4 4 4 4 4 <none> 6d23hkube-proxy 4 4 4 4 4 ...

ReplicaSet如果要实现滚动更新和蓝绿部署需要手工进行实现，所以这种类型的控制器并非是我们生产中所需要的，而更加高级的控制器称之为Deployment。 Deployment的工作过程和使用ReplicaSet手动实现蓝绿部署和滚动部署相似，Deployment会间接的使用1到多个ReplicaSet来管理Pod。 Deployment工作流程Deployment在更新Pod时会创建一个新的RS，由新的RS以新的pod模板创建出pod，然后逐渐将Pod切换到新版本上去。Deployment每一次更新都会创建出一个新的RS，其更新历史中默认允许保存10个RS。如果Deployment需要回滚时可以向前回滚9个版本。 需要注意的是虽然Deployment会保留历史RS，但是在历史中RS的pod为0，只有最新的RS其下的pod数为用户所定义的值。当回滚时才会将其pod副本的数量定义为用户所指定的值。 Deployment资源定义规范123456789101112131415161718apiVersion: apps/v1 # API群组及版本kind: Deployment # ...

简单的版本更新可能会使用到多个资源清单，而资源清单内仅部分不同，我们可以将这些不同的地方使用变量进行替换。 需要注意的是yaml格式的文件不支持变量，所以我们需要使用Shell命令来将变量替换后发送给kubectl 使用单个资源清单实现蓝绿部署示例1.编写replicaset资源清单 1234567891011121314151617181920212223242526root@k8s-master01:~/yaml/chapter08# vim replicaset-blue-gren.yamlapiVersion: apps/v1kind: ReplicaSetmetadata: name: rs-${DEPLOY}spec: minReadySeconds: 3 replicas: 2 selector: matchLabels: app: demoapp ctr: rs-${DEPLOY} version: ${VERSION} template: metadata: ...

当在k8s管理大量的应用时，这些应用之间存在大量的关系，紧密关系可以将其组织在同一个Pod中进行，而非紧密关系的应用之间则需要借助服务注册和服务发现将其关联起来，在K8s中实现服务注册和服务发现功能是由CoreDNS来实现的。 有时候各种应用之间存在各种复杂的关系，这时候就需要借助Service来实现应用的管理。 应用编排的核心所谓应用编排的核心就是应用的部署，扩展，更新，回滚 部署：在k8s中应用部署是由应用清单来定义的。 扩展：应用部署的核心还有扩展，扩展就是扩容，扩容又两种方法垂直扩容和横向扩容。在k8s中垂直扩容是指调大pod的资源限制。而横向扩容则是指多扩展几个pod副本。 更新：在如今敏捷开发的环境下，更新的速度将是非常快，我们要随时迭代旧的版本。 回滚：当更新后应用出现Bug时，则需要将版本进行回滚。之前部署的Pod都是裸Pod其不具备应用的扩展，更新，回滚的能力。而k8s上还有一种资源称之为控制器 控制器K8S上有各种控制器，有的用来控制节点，有的用来控制名称空间，还有一种用来管理Pod的成为Pod控制器。 整个K8S是由控制平面和数据平面组成： 控制平面：指的是 ...