Kube

参考资料： 官方文档 一、虚拟机安装 配置说明： windows下使用vbox，centos17.6 min版，kubernetes的版本是1.14.1, 安装如下三台机器： 192.168.56.15 k15 192.168.56.16 k16 192.168.56.17 k17 其中k15作为master，k16和k17作为node，虚拟机的安装重点关注网卡设置，设置两个网卡，第一个网卡（ifcfg-enp0s3）Host Only模式，第二个网卡（ifcfg-enp0s8）NAT模式，参见下图 二、虚拟机基本设置 本章节三台机器都执行，这里以k15为例 1.配置hostname hostnamectl --static set-hostname k15 2. 网卡设置 红色字体部分是需要修改和新增的配置 #网卡1 Local Bridge vi /etc/sysconfig/network-scripts/ifcfg- enp0s3 TYPE = Ethernet PROXY_METHOD = none BROWSER_ONLY = no BOOTPROTO = static DEFROUTE = yes IPV4_FAILURE_FATAL = no IPV6INIT = yes IPV6_AUTOCONF = yes IPV6_DEFROUTE = yes IPV6

目录 [toc] 什么是Kubeadm?   大多数与 Kubernetes 的工程师，都应该会使用 kubeadm 。它是管理集群生命周期的重要工具，从创建到配置再到升级; kubeadm 处理现有硬件上的生产集群的引导，并以最佳实践方式配置核心 Kubernetes 组件，以便为新节点提供安全而简单的连接流程并支持轻松升级。   在 Kubernetes 的文档 Creating a single master cluster with kubeadm 中已经给出了目前kubeadm的主要特性已经处于 Beta 状态了，在 2018 年就会转换成正式发布 (GA) 状态态，说明 kubeadm 离可以在生产环境中使用的距离越来越近了。    什么是容器存储接口(CSI)?   容器存储接口最初于 1.9 版本中作为 alpha 测试功能引入，在 1.10 版本中进入 beta 测试，如今终于进入 GA 阶段正式普遍可用。在 CSI 的帮助下， Kubernetes 卷层将真正实现可扩展性。通过 CSI ，第三方存储供应商将可以直接编写可与 Kubernetes 互操作的代码，而无需触及任何 Kubernetes 核心代码。事实上，相关规范也已经同步进入 1.0 阶段。    什么是CoreDNS?   在1.11中，官方宣布 CoreDNS

1、安装helm客户端 [root@cc-k8s01 work]# wget https://storage.googleapis.com/kubernetes-helm/helm-v2.14.0-rc.2-linux-amd64.tar.gz [root@cc-k8s01 work]# tar zxf helm-v2.14.0-rc.2-linux-amd64.tar.gz [root@cc-k8s01 work]# cd linux-amd64/ [root@cc-k8s01 linux-amd64]# mv helm /opt/k8s/bin [root@cc-k8s01 linux-amd64]# helm The Kubernetes package manager To begin working with Helm, run the 'helm init' command: $ helm init 2、安装tiller服务端 1.创建RBACq角色并授权 kubectl create serviceaccount tiller --namespace kube-system kubectl create clusterrolebinding tiller --clusterrole cluster-admin --serviceaccount=kube-system

什么是Kubernetes Helm?为什么要使用Helm? 前言 编写一堆Kubernetes配置文件是一件很麻烦的事情。对于一些容器，我们可能需要10多个yaml文件。维护它们是一个问题，而且在不同的环境中运行或使用相同的文件更是是一个噩梦。 我们可以使用一些 bash 技巧来替换某些值，但这是一个不好的做法。 这就是我们为什么要使用helm。 我应该提到，还有另一个很好的工具 ksonnet ，它以自己的方式进行“相同”操作。 在这篇文章中，我将介绍为什么Helm是Kubernetes应用程序必不可少的要素，将Kubernetes应用程序与Helm打包的过程，以及如何使用Helm部署可能具有的某些复杂应用程序。 为什么要使用helm 我最近在部署的微服务很复杂，我的发布文件目录中有65个以上的Kubernetes配置文件 ... o( ^▽^ )┛)。 主要问题是，我要如何把这个服务部署到多个环境中？ 或者如何使用Kubernetes制作CI/CD？ 当然做一些shell脚本是一个选择，但是我不是很喜欢这样做。 然后，我开始使用Kubernetes研究CI/CD pipline，发现一些团队正在将Helm集成到该过程中。 我们可以将理解为为像应用程序包那样的应用程序，在其中我们可以进行依赖管理，不同类型的钩子（安装前，升级前，安装后等），并且可以轻松升级或回滚。 安装

导读： kubeadm是Kubernetes官方提供的用于快速安装Kubernetes集群的工具，伴随Kubernetes每个版本的发布都会同步更新，kubeadm会对集群配置方面的一些实践做调整，通过实验kubeadm可以学习到Kubernetes官方在集群配置上一些新的最佳实践。 作者：青蛙小白 原文： https://blog.frognew.com/2019/07/kubeadm-install-kubernetes-1.15.html 最近发布的Kubernetes 1.15中，kubeadm对HA集群的配置已经达到beta可用，说明kubeadm距离生产环境中可用的距离越来越近了。 1.准备 1.1系统配置 在安装之前，需要先做如下准备。两台CentOS 7.6主机如下： cat /etc/hosts 192.168.99.11 node1 192.168.99.12 node2 如果各个主机启用了防火墙，需要开放Kubernetes各个组件所需要的端口，可以查看Installing kubeadm中的”Check required ports”一节。这里简单起见在各节点禁用防火墙： systemctl stop firewalld systemctl disable firewalld 禁用SELINUX： setenforce 0 vi /etc/selinux

一个在名称空间内的对象的完整url模板: Object_URL: /apis/<GROUP>/<VERSION>/namespaces/<NAMESPACE_NAME>/<KIND>[OJJECT_ID] role based access control , 将权限授权给角色role,让用户扮演某个角色,这样用户就会有对应的权限 . 许可授权:定义role时,会标明对哪些对象(object),做哪些操作(operations) 图解:名称空间级别的Role, 通过RoleBinding把用户user绑定到Role上 ,那么这个用户就有了管理整个名称空间的权限;集群级别的ClusterRole, 通过ClusterRoleBinding将用户user绑定到ClusterRole上 ,则该用户就有了管理整个集群的权限; 通过RoleBinding把用户user绑定到ClusterRole上,用户依然只有管理某个名称空间的权限 ,但这样做的好处是不用在每个ns中都创建Role了. 1.创建一个role kubectl create role pods-reader --verb=get,list,watch --resource=pods --dry-run -o yaml cat role-demo.yaml apiVersion: rbac.authorization.k8s.io

版本： 　　docker: 19.03.5 　　kubernetes: 1.17.0 　　istio: 1.4.3 步骤一：给ubuntu换源 https://www.cnblogs.com/lfri/p/10612037.html 步骤二：装docker sudo apt- get install -y apt-transport-https ca-certificates curl software-properties-common curl -fsSL https: // download.docker.com/linux/ubuntu/gpg | sudo apt-key add - sudo add-apt-repository " deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable " sudo apt- get update sudo apt- get install docker-ce=5:19.03.5~3-0~ubuntu-xenial sudo docker --version https://www.cnblogs.com/jiyang2008/p/9014960.html 步骤三：装kubernetes(k8s) sudo apt-key

注意：以下的命令都是在kubernetes 1.15中执行的，如果是其他版本，不保证效果。 1、创建kubernetes-dashboard服务和对应的pod kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v1.10.1/src/deploy/recommended/kubernetes-dashboard.yaml 如果发现该链接失效，请访问 https://github.com/kubernetes/dashboard ，然后查找最新的链接。 2、查看创建的服务和pod 3、重新创建一个可以供外网访问的Service # cat kubernetes-dashboard.yaml apiVersion: v1 kind: Service metadata: labels: k8s-app: kubernetes-dashboard name: kubernetes-dashboard namespace: kube-system spec: clusterIP: 10.97.14.63 externalTrafficPolicy: Cluster ports: - nodePort: 30443 port: 443 protocol: TCP targetPort: 8443

1、traefik 　　traefik：HTTP层路由，官网：http://traefik.cn/，文档：https://docs.traefik.io/user-guide/kubernetes/ 　　功能和nginx ingress类似。 　　相对于nginx ingress，traefix能够实时跟Kubernetes API 交互，感知后端 Service、Pod 变化，自动更新配置并热重载。Traefik 更快速更方便，同时支持更多的特性，使反向代理、负载均衡更直接更高效。 　　k8s集群部署Traefik，结合上一篇文章。 　　创建k8s-master-lb的证书： [root@k8s-master01 ~]# openssl req -x509 -nodes -days 365 -newkey rsa: 2048 -keyout tls.key -out tls.crt -subj " /CN=k8s-master-lb " Generating a 2048 bit RSA private key ................................................................................................................ +++ ...................

一、概述 　　1、上集中我们说到，官方文档提示说从k8s 1.11版本开始，将监控体系指标数据获取机制移向新一代的监控模型。也就意味着对于我们的k8s来讲现在应该有这样两种资源指标被使用。一种是资源指标，另一种是自定义指标。意思是说HeapSter提供了指标数据的收集，存储和监控的基本功能。并支持多个数据接收器。比如influxdb来存储指标数据，而后每个存储后端的代码本身都驻留在HeapSter仓库中。意思是HeapSter为了能够支持各种各样的存储后端他就不得不去适配驱动每一个存储后端，这其中包含我们刚刚说的inflxdb，更悲惨的是这每一个适配器都是由第三方组织研发的，第三方万一哪一天没兴趣了也就不维护了。以至于HeapSter中为了适配很多的存储后端，整合了近十几个后端存储的适配器。有些适配器自从整合至HeapSter以后再也没有修改过。但是HeapSter为此却不得不付出代码量很庞大的代价。所以这就意味着HeapSter的设计架构不适用于这种所谓云原生的监控体系。因为他会假设数据存储是一个原始的时间序列存储数据库。而且每个接收器都作为HeapSter核心代码的一部分。使得我们整个监控结构定义和使用起来越来越麻烦。而且维护起来代价也越来越大。所以这样子他开始去支持新一代的监控架构。这就是我们尝试着废弃HeapSter的原因。 　　2、当然k8s本身如此强大