Kube

Kubernetes 二进制安装 环境准备： 主机环境：做好主机名 hosts 文件映射 硬件 2cpu 2G 内存 192.168.30.21 k8s-master 192.168.30.22 k8s-node1 192.168.30.23 k8s-node2 关闭防火墙和 selinux 关闭防火墙： systemctl stop firewalld systemctl disable firewalld Iptables -F 关闭 selinux ： $ sed -i 's/enforcing/disabled/' /etc/selinux/config $ setenforce 0 临时 $ setenforce 0 1. 每台机器安装 docker-ce 这里是 Centos7安装方式 安装依赖包 $ sudo yum install -y yum-utils \ device-mapper-persistent-data \ lvm2 添加 Docker软件包源 $ sudo yum-config-manager \ --add-repo \ https://download.docker.com/linux/centos/docker-ce.repo 安装 Docker-ce $ sudo yum install docker-ce 启动 Docker $ sudo

一、kubenetes搭建方式有三种： 1、minikube （通常在测试环境使用，不要在生产环境中使用） 2、kubeadm （是一种快速部署kubernetes的方式，部署相对简单，可以在生产环境中应用） 3、二进制方式安装kubernetes （安装过程复杂，比较容易踩坑） 二、使用kubeadm方式安装kubernetes： 1、环境： IP地址 主机名 192.168.1.100 k8s-master 192.168.1.101 k8s-node1 虚拟机配置：操作系统：CentOS7.5 　　　　　　CPU最好2核心数以上 　　　　　　内存最好2GB以上 2、部署前的条件 　　　　2.1、关闭防火墙： 1 systemctl disable firewalld #关闭防火墙开机自启 2 systemctl stop firewalld #关闭防火墙 　　　　2.2、关闭selinux 1 setenforce o #暂时关闭selinux 　　　　 2.3、关闭swap 1 swapoff -a 　　　　2.4、创建k8s配置文件 1 vi /etc/sysctl.d/ k8s.conf 2 3 net.bridge.bridge-nf-call-ip6tables = 1 4 net.bridge.bridge-nf-call-iptables = 1 5 net

前言 最近2年相信大家都听过kubernetes这种新容器编排工具，越来越多的公司也去学习相关技术，并运用它去解决公司的问题，它在开源社区也是非常火，大小不断的k8smeeting以及容器相关的会议。这火爆程度和在2011年到2016年之间非常火的Openstack非常相似，不论是社区还是公司都是积极的去推动。笔者处在互联网之中，也接触学习过这两套系统，对他们相关技术也是非常的热爱，也在慢慢的根据不同应用场景在公司去推动相关业务转型，如相关服务的容器化技术转型等等，我就在这表达一下自己的一些看法与意见。加深理解大家对openstack 和kubernetes相关体系的理解与学习。 趋势 先简单说下目前的趋势，目前来看Openstack整个项目趋向于稳定，活跃程度相比之前有所下滑，从整个发版速度来看，由原来的半年一个relase转为一年一个relase, 团队的整个核心也将更多精力放在关于系统的可用性和稳定性优化，不过这并不是说他已经过时了，他是经过了上万台服务器的检验，是一个非常好的云操作系统，还是有拥有大量的用户和热爱者，如ebuy, 沃尔玛，京东，美团以及相关的私有云企业服务。 而kubernetes则是业界的新宠，可以用如日中天来形容，首先是Google自家对它的大力支持，包括前段时间Google Cloud捐赠给kubernetes社区800万美元的捐赠就能看出重视程度

k8s 对外暴露服务的方法 向 k8s 集群外部暴露服务的方式有三种： nodePort，LoadBalancer 和本文要介绍的 Ingress。每种方式都有各自的优缺点，nodePort 方式在服务变多的情况下会导致节点要开的端口越来越多，不好管理。而 LoadBalancer 更适合结合云提供商的 LB 来使用，但是在 LB 越来越多的情况下对成本的花费也是不可小觑。Ingress 是 k8s 官方提供的用于对外暴露服务的方式，也是在生产环境用的比较多的方式，一般在云环境下是 LB + Ingress Ctroller 方式对外提供服务，这样就可以在一个 LB 的情况下根据域名路由到对应后端的 Service，有点类似于 Nginx 反向代理，只不过在 k8s 集群中，这个反向代理是集群外部流量的统一入口。 Service 虽然解决了服务发现和负载均衡的问题，但对外访问的时候，NodePort类型需要在外部搭建额外的负载均衡，而LoadBalancer需要Kubernetes必须跑在支持的cloud provider上面。 Ingress就是为了解决这些限制的。 Ingress 是一个规则的集合，它允许集群外的流量通过一定的规则到达集群内的 Service 。 request--->ingress--->service. Ingress由三个组件组成： 1.

概述： Kubernetes Service 定义了这样一种抽象：一个 Pod 的逻辑分组，一种可以访问它们的策略 —— 通常称为微服务。这一组 Pod 能够被 Service 访问到，通常是通过 Label Selector实现的。 举个例子，考虑一个图片处理 backend，它运行了3个副本。这些副本是可互换的 —— frontend 不需要关心它们调用了哪个 backend 副本。然而组成这一组 backend 程序的 Pod 实际上可能会发生变化，frontend 客户端不应该也没必要知道，而且也不需要跟踪这一组 backend 的状态。Service 定义的抽象能够解耦这种关联。 对 Kubernetes 集群中的应用，Kubernetes 提供了简单的 Endpoints API，只要 Service 中的一组 Pod 发生变更，应用程序就会被更新。对非 Kubernetes 集群中的应用，Kubernetes 提供了基于 VIP 的网桥的方式访问 Service，再由 Service 重定向到 backend Pod。 对一些应用（如 Frontend）的某些部分，可能希望通过外部（Kubernetes 集群外部）IP 地址暴露 Service。 Service 类型 ClusterIP：通过集群的内部 IP 暴露服务，选择该值，服务只能够在集群内部可以访问

各个证书的过期时间 /etc/kubernetes/pki/apiserver.crt #1年有效期 /etc/kubernetes/pki/front-proxy-ca.crt #10年有效期 /etc/kubernetes/pki/ca.crt #10年有效期 /etc/kubernetes/pki/apiserver-etcd-client.crt #1年有效期 /etc/kubernetes/pki/front-proxy-client.crt #1年有效期 /etc/kubernetes/pki/etcd/server.crt #1年有效期 /etc/kubernetes/pki/etcd/ca.crt #10年有效期 /etc/kubernetes/pki/etcd/peer.crt #1年有效期 /etc/kubernetes/pki/etcd/healthcheck-client.crt #1年有效期 /etc/kubernetes/pki/apiserver-kubelet-client.crt #1年有效期 可用于检查证书过期时间： 方法1 kubeadm alpha certs check-expiration 方法2 openssl x509 -noout -dates -in /etc/kubernetes/pki/apiserver.crt

修改kubeadm证书过期时间 2018-11-07 文章目录 修改kubeadm证书过期时间 代码编译 修改代码 kubernetes集群三步安装 修改kubeadm证书过期时间 本文通过修改kubeadm源码让kubeadm默认的一年证书过期时间修改为99年 我已经编译好了一个放在了github上，有需要的可以直接下 使用方法: 1 2 3 [root@dev- 86 - 202 ~] # chmod +x kubeadm && cp kubeadm /usr/bin [root@dev- 86 - 202 ~] # rm /etc/kubernetes/pki/ -rf [root@dev- 86 - 202 ~] # kubeadm alpha phase certs all --config kube/conf/kubeadm.yaml 更新kubeconfig 1 2 3 [root@dev- 86 - 202 ~] # rm -rf /etc/kubernetes/*conf [root@dev- 86 - 202 ~] # kubeadm alpha phase kubeconfig all --config ~/kube/conf/kubeadm.yaml [root@dev- 86 - 202 ~] # cp /etc/kubernetes/admin.conf

k8s Ingress和ingress控制器 ingress架构图简介 我们知道service的表现形式为IP:PORT，即工作在第四层传输层（TCP/IP层），那么对于不同的URL地址经常对应用不同的后端服务或者虚拟服务器，这些应用层的转发机制仅通过kubernetes的service机制是无法实现的，这种情况我么可以使用ingress策略定义和一个具体的ingress Controller，两者结合实现一个完整的Ingress 负载均衡，这个负载均衡是基于nginx七层反向代理来实现的，ingress工作原理如下图： 外部客户端通过访问负载均衡器，然后调度到service上，然后在调度到IngressController，IngressController通过Ingress规则（域名或虚拟主机）访问到后端pod，而在Ingress规则当中对应的主机是又service分组来设定的，可以看到，这幅图有2种service，最上面的service是用来对外提供服务的，而下面2个service仅仅是用来分pod组的 ingress安装和配置 在github上下载相关yaml文件 下载mandatory.yaml文件 wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.20.0/deploy

随着容器技术的发展成熟，越来越多的组件迁移到容器， 在技术迁移过程中，数据库，游戏，AI 这些组件对容器网络性能（时延，吞吐，稳定性）提出了更高的要求 。为了得到更优的时延和吞吐表现，各大云厂商都在致力于缩短节点内容器的网络访问链路，让数据包能尽可能快地转发到容器网卡。 腾讯云 容器服务 TKE 借助智能网卡推出下一代容器网络方案，该方案实现了一个 Pod 独占一张弹性网卡，不再经过节点网络协议栈 （default namespace），极大缩短了容器访问链路，缩短了访问时延，并使 PPS 可以达到整机上限。该方案实现了 短链接场景下 QPS 相比之前容器网络方案（策略路由方案，网桥方案）提升 50%-70%；长链接场景下 QPS 提升 40%-60%。 由于不再经过节点网络协议栈，传统基于 iptables 和 IPVS 的 ClusterIP service 访问方案不能直接适用于该方案。为了实现该方案下 Pod 可以直接访问 ClusterIP service，TKE 推出 share-NS IPVS 方案，使得在容器网络命名空间下也可以访问到节点网络协议栈的 IPVS 规则，同时配合 CLB 直通 Pod，实现了完整意义上的弹性网卡直通。 该方案实现了针对 ClusterIP service 短链接场景下 QPS 相比 iptables 方案提升 40%-60%，IPVS

一、摘要 在上一篇文章，链接如下： https://www.cnblogs.com/xiao987334176/p/11434849.html 镜像打的是latest版，如果需要回滚的话，就比较麻烦了。 因此，需要修改为参数化构建。 镜像的版本，使用时间戳 。 本文采用的环境，依然是上一篇的环境，就不多介绍了。 二、参数化构建 发布 修改 ph任务，勾选 此项目参数化构建，点击 添加参数 ，选择 Choice Parameter 输入参数，这里有2个固定选项，分别是发布和回滚，再点击底部的 添加参数， 选择 String Parameter 输入参数，这个版本号，就是来回滚的。 再进入到Bulid，修改执行命令 case $Status in Deploy) echo " Status:$Status " bash -x /root/docker_dir/deploy_docker. sh echo " Completing! " ;; Rollback) echo " Status:$Status " echo " Version:$Version " bash -x /root/docker_dir/rollback_docker. sh echo " Completing! " ;; * ) exit ;; esac 效果如下： 修改3个shell脚本 deploy