k8s

一、Helm概述 1.Helm简介 helm类似于Linxu系统下的包管理工具，如yum、apt等，主要用于Kubernetes应用程序 Chart的创建、打包、发布以及创建和管理本地和远程的Chart仓库。 2.Helm组件 helm：本地客户端工具，主要用于kubernetes应用chart的创建/打包/发布以及创建和管理和远程Chart仓库。 Tiller：helm的服务端，部署于kubernetes内，Tiller接受helm的请求，并根据chart生成kubernetes部署文件（helm称为release），然后提交给 Kubernetes创建应用。Tiller还提供了Release的升级、删除、回滚等一系列功能。 Chart：helm的软件包，采用tar格式，其中包含运行一个应用所需的所有镜像/依赖/资源定义等，还可能包含kubernetes集群中服务定义，类似于yum的rpm文件 Release：在kubernetes中集群中运行的一个Chart实例，在同一个集群上，一个Chart可以安装多次，每次安装均会生成一个新的release。 Repository：用于发布和存储Chart的仓库 二、Helm部署 1.安装Helm # wget https://get.helm.sh/helm-v2.14.3-linux-amd64.tar.gz # tar -zxvf

一、Rook部署 Rook是一个开源的cloud-native storage orchestrator，为各种存储解决方案提供平台、框架和支持，以便与云原生环境本地集成。Rook通过自动化部署、引导、配置、置备、扩展、升级、迁移、灾难恢复、监控和资源管理来实现此目的。Rook使用底层云本机容器管理、调度和编排平台提供的工具来实现它自身的功能。 1.使用Helm安装Rook Operator Ceph Operator Helm Chart # helm repo add rook-release https://charts.rook.io/release # helm install --namespace rook-ceph rook-release/rook-ceph --name rook-ceph 2.在k8s集群中三个Node节点上新增一块磁盘sdb [root@k8s-node01 ~]# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 200G 0 disk sdb 8:16 0 50G 0 disk 3.创建Rook Cluster # git clone https://github.com/rook/rook.git # cd rook/cluster/examples/kubernetes

转载链接： https://www.kubernetes.org.cn/5906.html 我本人看到这几个常用命令，分享下： 滚动升级相关命令，记得加上对应的命名空间 $ kubectl set image deploy/nginx nginx=nginx:1.7.9 --record $ kubectl set image deploy/nginx nginx=nginx --record $ kubectl rollout status deploy nginx #查看升级状态 $ kubectl rollout pause deployment nginx #升级暂停 $ kubectl rollout resume deployment nginx #恢复升级 $ kubectl describe deploy nginx #查看升级详情 $ kubectl rollout history deploy/nginx #查看升级历史 deployment.extensions/nginx REVISION CHANGE-CAUSE 4 kubectl set image deploy/nginx nginx=nginx:1.7.9 --record=true 5 kubectl set image deploy/nginx nginx=nginx --record=true

1 标签 1.1 为什么要有标签？   在微服务架构中，部署的微服务数量很容器达到几十个，这些组件可能是副本（部署同一组件的多个副本）和多个不同的发布版本（stable、beta、canary等）同时运行。导致K8S系统中会出现多个pod，如果没有机制去组织这些组件，极容易产生混乱。需要一种能够基于任意标准将上述pod组织成更小群体的方式，这个时候就产生了 标签 ，标签可以组织pod和其他K8S对象。 1.2 标签介绍   标签是一种简单却功能强大的K8S特性，可以附加到K8S资源的任意键值对，可以通过 标签选择器 筛选出需要寻找的确切标签的资源。在资源内标签的key需唯一，一个资源可拥有多个标签。   K8S中的任意API对象都是通过Label进行标识、实质是一系列key/value键值对，其中key与value由用户自己指定。 金丝雀发布：在部署新版本时，先只让一小部分用户体验新版本以观察新版本的表现，然后再向所有用户进行推广，这样可防止暴露有问题的版本给过多的用户。 1.3 标签命令 列出pods的标签 $ kubectl get po --show-labels 查看具体标签 $ kubectl get po -L label_key1, label_key2 添加标签 $ kubectl label po po_name label_key=label_value 其中，

一、利用ansible部署kubernetes集群环境准备 　 　基 于二进制方式部署和利用ansible-playbook实现自动化：既提供一键安装脚本，也可以分步执行安装各个组件，同时讲解每一步主要参数配置和注意事项；二进制方式部署有助于理解系统各组件的交互原理和熟悉组件启动参数，有助于快速排查解决实际问题。 版本组件 ： 　　kubernetes v1.9.7 　　etcd v3.3.4 　　docker 18.03.0-ce 　　calico/node:v3.0.6 　　calico/cni:v2.0.5 　　calico/kube-controllers:v2.0.4 　　centos 7.3+ 集群规划和基础参数设定： 　　1.高可用集群所需节点配置如下： 　　　　部署节点×1：运行ansible脚本的节点 　　　　etcd节点×3：注意etcd集群节点必须是1，3，5，7……奇数个节点 　　　　master节点×1：运行集群主要组件 　　　　node节点×3：真正应用部署的节点，根据需要增加机器配置和节点数 　　2.在部署节点准备ansible：使用ansible的docker环境启动： 　　　　1° 下载内部源配置脚本并运行脚本： wget http://download2.yunwei.edu/shell/yum-repo.shbash yum-repo.sh 　

apiVersion: v1 kind: Pod metadata: name: liveness-httpget namespace: default spec: containers: - name: liveness-httpget-container image: httpd imagePullPolicy: IfNotPresent ports: - name: http containerPort: 80 livenessProbe: httpGet: port: http path: /index.html initialDelaySeconds: 1 periodSeconds: 3 timeoutSeconds: 10 检测是否存在/index.html文件，有则正常，没有则重启pod 来源： 51CTO 作者： 头发太长l 链接： https://blog.51cto.com/11954248/2477634

apiVersion: v1 kind: Pod metadata: name: liveness-tcp namespace: default spec: containers: - name: liveness-tcp-container image: httpd imagePullPolicy: IfNotPresent livenessProbe: initialDelaySeconds: 5 timeoutSeconds: 10 tcpSocket: port: 8080 periodSeconds: 3 镜像默认端口应该是80，但是yaml文件故意写成8080，tcp检测失败，pod会反复执行重启操作知道检测到80端口 来源： 51CTO 作者： 头发太长l 链接： https://blog.51cto.com/11954248/2477637

k8s更新迭代比较快，apiVersion也在不断变化中，每个版本的对应的apiVersion略有不同，推荐大家去看官方文档： https://kubernetes.io/docs/reference/ 。 对照表如下： Kind apiVersion CertificateSigningRequest certificates.k8s.io/v1beta1 ClusterRoleBinding rbac.authorization.k8s.io/v1 ClusterRole rbac.authorization.k8s.io/v1 ComponentStatus v1 ConfigMap v1 ControllerRevision apps/v1 CronJob batch/v1beta1 DaemonSet extensions/v1beta1 Deployment extensions/v1beta1 Endpoints v1 Event v1 HorizontalPodAutoscaler autoscaling/v1 Ingress extensions/v1beta1 Job batch/v1 LimitRange v1 Namespace v1 NetworkPolicy extensions/v1beta1 Node v1 PersistentVolumeClaim

某厂面试归来，发现自己落伍了！>>> 从 2019 年初开始，阿里巴巴云原生应用平台团队开始逐步在整个阿里经济体内，基于标准应用定义与交付模型进行应用管理产品与项目统一架构升级的技术工作。 事实上，早在 2018 年末，当 Kubernetes 项目正式成为阿里巴巴的应用基础设施底盘之后，阿里内部以及阿里云产品线在应用管理领域的碎片化问题就开始日渐凸显出来。 尤其是在云原生生态日新月异的今天，阿里巴巴与阿里云的应用管理产品架构（包括阿里内部 PaaS 和云上 PaaS 产品），如何以最佳姿态拥抱云原生生态、如何以最高效的技术手段借助生态日新月异的能力构建出更强大的 PaaS 服务，而不是重复造轮子甚至和生态“背道而驰”，很快就成为了阿里团队亟待解决的重要技术难题。 但棘手的是，这个问题并不是简单把 PaaS 迁移或者集成到 Kubernetes 上来就能够解决的：PaaS 与 Kubernetes 之间，从来就没有存在这样一条清晰的分界线，可是 Kubernetes 本身又并不是面向最终用户设计的。 如何既让全公司的研发和运维充分享受云原生技术体系革新带来的专注力与生产力提升，又能够让现有 PaaS 体系无缝迁移、接入到 Kubernetes 大底盘当中，还要让新的 PaaS 体系把 Kubernetes 技术与生态的能力和价值最大程度的发挥出来，而不是互相“屏蔽”甚至“打架”

一、删除node节点 1、先查看一下这个node节点上的pod信息 2、驱逐这个node节点上的pod # kubectl drain node06 --delete-local-data --force --ignore-daemonsets 3、删除这个node节点 # kubectl delete nodes node06 4、然后在node06这个节点上执行如下命令： kubeadm reset systemctl stop kubelet systemctl stop docker rm -rf /var/lib/cni/ rm -rf /var/lib/kubelet/* rm -rf /etc/cni/ ifconfig cni0 down ifconfig flannel.1 down ifconfig docker0 down ip link delete cni0 ip link delete flannel.1 systemctl start docker systemctl start kubelet 如果不做上面的操作的话会导致这个节点上的pod无法启动 ，具体报错信息为：networkPlugin cni failed to set up pod "alertmanager-main-1_monitoring" network: failed to