Knative-初体验CICD-极速入门

Knative 社区很早就在讨论用 Tekton 替换 Build 模块的事宜。Knative Build 官方已经正式说明不再建议使用 Knative Build 了。 如果你知道 Knative Build 是什么相信你理解起 Tekton 就是很容易的一件事了。 Knative Build 对自己的一句话概述是:A Kubernetes-native Build resource.Tekton 对自己的一句话概述是: A K8s-native Pipeline resource. https://tekton.dev可以看到两者的定位非常相近,而且在功能上 Tekton 的设计更加的丰富、完整,这也是社区最终采用 Tekton 的原因。接下来我们就看一下 Tekton 的核心概念。Tekton 极速入门Tekton 主要由如下五个核心概念组成: TaskTaskRunPipelinePipelineRunPipelineResource这五个概念每一个都是以 CRD 的形式提供服务的,下面分别简述一下这五个概念的含义。Task Task 就是一个任务执行模板,之所以说 Task 是一个模板是因为 Task 定义中可以包含变量,Task 在真正执行的时候需要给定变量的具体值。Tekton 的 Task 很类似于一个函数的定义,Task 通过 inputs.params 定义需要哪些入参,并且每一个入参还可以指定默认值。Task 的 steps 字段表示当前 Task 是有哪些子步骤组成的。每一个步骤具体就是一个镜像的执行,镜像的启动参数可以通过 Task 的入参使用模板语法进行配置。 apiVersion: tekton.dev/v1alpha1kind: Taskmetadata: name: task-with-parametersspec: inputs: params: - name: flags type: array - name: someURL type: string steps: - name: build image: registry.cn-hangzhou.aliyuncs.com/knative-sample/alpine:3.9 command: ["sh", "-c"] args: [ "echo ${inputs.params.flags} ; echo ${someURL}"]TaskRun ...

August 7, 2019 · 5 min · jiezi

如何使用curl访问k8s的apiserver

使用TOKEN授权访问api-server在k8s运维场景中比较常见, apiserver有三种级别的客户端认证方式 1,HTTPS证书认证:基于CA根证书签名的双向数字证书认证方式 2,HTTP Token认证:通过一个Token来识别合法用户 3,HTTP Base认证:通过用户名+密码的认证方式 通常的运维场景使用第二种Token较为方便Token的权限是关联service account, # kubectl describe secrets admin-token-2q28f -n kube-systemName: admin-token-2q28fNamespace: kube-systemLabels: <none>Annotations: kubernetes.io/service-account.name: admin kubernetes.io/service-account.uid: 93316ffa-7545-11e9-b617-00163e06992dType: kubernetes.io/service-account-tokenData====ca.crt: 1419 bytesnamespace: 11 bytestoken: eyJhbGciOiJ******Service Account 的权限来自Clusterrolebinding-->ClusterRole # kubectl describe serviceaccount admin -n kube-systemName: adminNamespace: kube-systemLabels: <none>Annotations: kubectl.kubernetes.io/last-applied-configuration: {"apiVersion":"v1","kind":"ServiceAccount","metadata":{"annotations":{},"name":"admin","namespace":"kube-system"}}Image pull secrets: <none>Mountable secrets: admin-token-2q28fTokens: admin-token-2q28fEvents: <none>通过clusterrolebinding 可以拿到ClusterRole对应的rolename # kubectl get clusterrolebinding admin -o yamlapiVersion: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"rbac.authorization.k8s.io/v1beta1","kind":"ClusterRoleBinding","metadata":{"annotations":{},"name":"admin"},"roleRef":{"apiGroup":"rbac.authorization.k8s.io","kind":"ClusterRole","name":"cluster-admin"},"subjects":[{"kind":"ServiceAccount","name":"admin","namespace":"kube-system"}]} creationTimestamp: 2019-05-13T06:08:49Z name: admin resourceVersion: "1523" selfLink: /apis/rbac.authorization.k8s.io/v1/clusterrolebindings/admin uid: 93356439-7545-11e9-b617-00163e06992droleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cluster-adminsubjects:- kind: ServiceAccount name: admin namespace: kube-system这个role是什么权限? ...

June 24, 2019 · 2 min · jiezi

Pod在多可用区worker节点上的高可用部署

一、 需求分析当前kubernetes集群中的worker节点可以支持添加多可用区中的ECS,这种部署方式的目的是可以让一个应用的多个pod(至少两个)能够分布在不同的可用区,起码不能分布在同一个可用区,已达到高可用或者同城灾备的部署。二、 效果图三、 实现原理为了实现上述的效果,kubernetes提供了pod的亲和性和反亲和性来保证pod在节点级别,可用区级别的高可用部署;具体的值为topologyKey:failure-domain.beta.kubernetes.io/zone。四、 实现步骤在ACK上创建完集群后,不论从哪个可用区添加节点,都会对该节点打上对应的可用区标签,比如,一个节点是属于北京可用区a的,那么在加入到kubernetes集群后,该节点上会有一个这样的标签:failure-domain.beta.kubernetes.io/zone: cn-beijing-a。在有了上述标签后,对应用进行多可用区部署时,我们就可以使用一下yaml文件来使不同的pod分配到不同的可用区。 Yaml文件示例:apiVersion: apps/v1kind: Deploymentmetadata: name: redis-cachespec: selector: matchLabels: app: store replicas: 3 template: metadata: labels: app: store spec: affinity: podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: app operator: In values: - store topologyKey: “failure-domain.beta.kubernetes.io/zone” containers: - name: redis-server image: redis:3.2-alpine上面yaml文件中的podAntiAffinity:部分规定了node的反亲和性,并且由于使用了topologyKey: “failure-domain.beta.kubernetes.io/zone”,如果failure-domain.beta.kubernetes.io/zone这个key有三种value,比如cn-beijing-a,cn-beijing-b,cn-beijing-c;那么pod会被分配在这三个不同的可用区。并且由于使用了preferredDuringSchedulingIgnoredDuringExecution,所以如果pod个数大于可用区个数的话,pod会尽可能的放在不同的可用区,最后会出现多出来的pod会与原有pod在同一个可用区。上面的使用方式还有很多种,包括node级别的,详细请参考:https://kubernetes.io/docs/co…由于云盘不能跨可用区挂载,如果有pod使用了存储卷,该pod需要被调度到与存储卷相同的可用区的机器上。其他存储卷比如NAS,OSS是可以采用上述部署方式的。本文作者:朱延生阅读原文本文为云栖社区原创内容,未经允许不得转载。

March 18, 2019 · 1 min · jiezi