Kube

本文内容 本文致力于介绍K8s一些基础概念与串联部署应用的主体流程，使用Minikube实操 基础架构概念回顾 温故而知新，上一节 【K8S学习笔记】初识K8S 及架构组件 我们学习了K8s的发展历史、基础架构概念及用途，本节讲的内容建立在其上，有必要把之前的架构小节提出来回顾下： K8s架构分为控制平台(位于的Master节点)与执行节点Node 控制平台包含： kube-apiserver（访问入口，接收命令） etcd（KV数据库，保存集群状态与数据） kube-scheduler（监控节点状态，调度容器部署） kube-controller-manager（监控集群状态，控制节点、副本、端点、账户与令牌） cloud-controller-manager（控制与云交互的节点、路由、服务、数据卷） 执行节点包含： kubelet（监控与实际操作容器） kube-proxy（每个节点上运行的网络代理，维护网络转发规则，实现了Service） 容器运行时环境CRI（支持多种实现K8s CRI的容器技术） 接下来需要引入 Pod 与 Service 的概念，这也是在上一篇文章中未给出的 Pod、Service与Label概念 Pod概念与结构 Pod 是 K8s最重要的基本概念，官网给出概念：Pod是Kubernates可调度的最小的、可部署的单元。怎么理解呢？最简单的理解是

kubectl tab补全 yum install -y bash-completion source /usr/share/bash-completion/ bash_completion source < (kubectl completion bash) echo "source <(kubectl completion bash)" >> ~/.bashrc 1.1 Common Commands Name Command Run curl test temporarily kubectl run --generator=run-pod/v1 --rm mytest --image=yauritux/busybox-curl -it Run wget test temporarily kubectl run --generator=run-pod/v1 --rm mytest --image=busybox -it wget Run nginx deployment with 2 replicas kubectl run my-nginx --image=nginx --replicas=2 --port=80 Run nginx pod and expose it kubectl run my-nginx --restart=Never --image=nginx -

引言 最近做边缘计算项目，因为没有基础，所以首先学习Kubernetes。感觉系统的中文入门资料比较少，只找到《Kubernetes权威指南》（龚正、吴治辉等著，下称《指南》），照着第一章的demo教程编写，前前后后遇到不少问题（笔者可是连MySQL都没有学过啊！），也是找了好多资料才解决。所以从头写一下如何配置一个单机版MySQL+Tomcat的demo，希望能给陷入同样困境的同学一点帮助。 文章较长，如果你已经按照《指南》的demo走了一遍，但是遇到了问题，可以直接看最后的“坑点总结”中的解决方案能否解决你的问题。 知识准备和环境准备 前导知识 本着对零基础的同学友好的态度（尤其是像笔者这样的非科班生555），前排提示阅读本文前你至少需要以下知识： 掌握虚拟机的使用，尤其是网络的配置 Linux的使用，尤其是CentOS 7的systemctl功能 了解如何更换软件安装源（主要是yum和docker） 了解docker和容器的基本概念 大致了解yaml 可能的科学上网方法（但一般可以通过更换软件源代替） 也就是说，以上的知识本文不会详细展开。如果其中有读者从来没有听说过的概念，最好先学习一下。 实验环境 笔者的实验环境： Win10 + VMWare14中安装CentOS 7（带GUI），桥接模式上网 之所以强调是CentOS 7（包括RHEL 7）

背景 某环境客户部署了一个kubernetes集群，发现flannel的pod一直重启，始终处于CrashLoopBackOff状态。 排查 对于始终CrashLoopBackOff的pod，一般是应用本身的问题，需要查看具体pod的日志，通过 kubectl logs -f --tail -n kube-system flannel-xxx 显示，“pod cidr not assigned”，然后flannel退出 检查日志显示的节点10.0.0.17的cidr，发现确实为空，而正常的环境却是正常的。 检查flannel的启动参数，发现为 --kube-subnet-mgr ,–kube-subnet-mgr代表其使用kube类型的subnet-manager。该类型有别于使用etcd的local-subnet-mgr类型，使用kube类型后，flannel上各Node的IP子网分配均基于K8S Node的spec.podCIDR属性—" contact the Kubernetes API for subnet assignment instead of etcd. ",而在第2步，我们已经发现节点的podcidr为空。 node节点分配podCIDR，需要kube-controller-manager开启 allocate-node-cidrs 为true，它和

背景 某环境客户部署了一个kubernetes集群，发现flannel的pod一直重启，始终处于CrashLoopBackOff状态。 排查 对于始终CrashLoopBackOff的pod，一般是应用本身的问题，需要查看具体pod的日志，通过 kubectl logs -f --tail -n kube-system flannel-xxx 显示，“pod cidr not assigned”，然后flannel退出 检查日志显示的节点10.0.0.17的cidr，发现确实为空，而正常的环境却是正常的。 检查flannel的启动参数，发现为 --kube-subnet-mgr ,–kube-subnet-mgr代表其使用kube类型的subnet-manager。该类型有别于使用etcd的local-subnet-mgr类型，使用kube类型后，flannel上各Node的IP子网分配均基于K8S Node的spec.podCIDR属性—" contact the Kubernetes API for subnet assignment instead of etcd. ",而在第2步，我们已经发现节点的podcidr为空。 node节点分配podCIDR，需要kube-controller-manager开启 allocate-node-cidrs 为true，它和

本文来源：鲜枣课堂 2010年，几个搞IT的年轻人，在美国旧金山成立了一家名叫“dotCloud”的公司。 这家公司主要提供基于PaaS的云计算技术服务。具体来说，是和LXC有关的容器技术。 LXC，就是Linux容器虚拟技术（Linux container） 后来，dotCloud公司将自己的容器技术进行了简化和标准化，并命名为——Docker。 Docker技术诞生之后，并没有引起行业的关注。而dotCloud公司，作为一家小型创业企业，在激烈的竞争之下，也步履维艰。 正当他们快要坚持不下去的时候，脑子里蹦出了“开源”的想法。 什么是“开源”？开源，就是开放源代码。也就是将原来内部保密的程序源代码开放给所有人，然后让大家一起参与进来，贡献代码和意见。 Open Source，开源 有的软件是一开始就开源的。也有的软件，是混不下去，创造者又不想放弃，所以选择开源。自己养不活，就吃“百家饭”嘛。 2013年3月，dotCloud公司的创始人之一，Docker之父，28岁的Solomon Hykes正式决定，将Docker项目开源。 Solomon Hykes（今年刚从Docker离职） 不开则已，一开惊人。 越来越多的IT工程师发现了Docker的优点，然后蜂拥而至，加入Docker开源社区。 Docker的人气迅速攀升，速度之快，令人瞠目结舌。 开源当月，Docker 0

借鉴博客：https://www.cnblogs.com/xkops/p/6169034.html 此博客里面有每个k8s配置文件的注释：https://blog.csdn.net/qq_35904833/article/details/78190257 啊西吧，啊西吧，根据上面的博客终于安装成功了。妈的，网上大部分博客安装k8s配置写得乱七八槽的，终于找到一篇条理清晰，安装详细的k8s安装博客啦，哈哈哈哈，不容易啊快三个星期了，从狗屁不懂搞这玩意。 下面写一写我自己的安装流程： 　　一、安装准备： 　　　　　　准备两台服务器（我用的是CentOS7系统）：192.168.26.227，192.168.26.228 　　　　　　一主一从： 　　　　　　　　master机：192.168.26.227 　　　　　　　　node机：192.168.26.228 　　　　　　简单说一下k8s： 　　　　　　　　k8s是个什么玩意？ 　　　　　　　　　　可以这样去理解：k8s全称：Kubernetes，它可以看作是一个分布式系统支撑平台。　　　　　　　　　　 　　　　　　　　我们为什么要用k8s集群？ 　　　　　　　　　　故障自愈： 　　　　　　　　　　　　k8s这个玩意可以监控容器运行，我们把项目放到容器里。由于一些外部内部原因服务器承受不住压力，如果主节点上的容器突然挂了

云栖号资讯：【 点击查看更多行业资讯 】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！ 作者 | 新胜 阿里云技术专家 导读： OpenYurt 开源两周以来，以非侵入式的架构设计融合云原生和边缘计算两大领域，引起了不少行业内同学的关注。阿里云推出开源项目 OpenYurt，一方面是把阿里云在云原生边缘计算领域的经验回馈给开源社区，另一方面也希望加速云计算向边缘延伸的进程，并和社区共同探讨未来云原生边缘计算架构的统一标准。为了更好地向社区和用户介绍 OpenYurt，我们特地推出【深度解读OpenYurt】系列文章，本文为系列文章的第三篇，一一介绍了 OpenYurt 中组件 YurtHub 的扩展能力。 OpenYurt 介绍 阿里云边缘容器服务上线 1 年后，正式开源了云原生边缘计算解决方案 OpenYurt，跟其他开源的容器化边缘计算方案的区别在于：OpenYurt 秉持 Extending your native Kubernetes to edge 的理念，对 Kubernetes 系统零修改，并提供一键式转换原生 Kubernetes 为 openyurt，让原生 K8s 集群具备边缘集群能力。 同时随着 OpenYurt 的持续演进，也一定会继续保持如下发展理念： 非侵入式增强 K8s 保持和云原生社区主流技术同步演进 YurtHub 架构说明

一、环境 服务器信息 主机名 IP 备注 k8s-master1 192.168.0.216 Master1,etcd1,node节点 k8s-master2 192.168.0.217 Master2,etcd2,node节点 k8s-master3 192.168.0.218 Master3,etcd3,node节点 slb lb.ypvip.com.cn 外网阿里slb域名 本环境使用阿里云， API Server 高可用通过 阿里云SLB 实现，如果环境不在云上，可以通过 Nginx + Keepalived，或者 HaProxy + Keepalived等实现。 服务版本与K8S集群说明 阿里slb 设置 TCP监听 ，监听6443端口(通过四层负载到master apiserver)。 所有 阿里云ECS主机 使用 CentOS 7.6.1810 版本，并且内核都升到 5.x 版本。 K8S 集群使用 Iptables 模式 （kube-proxy 注释中预留 Ipvs 模式配置） Calico 使用 IPIP 模式 集群使用默认 svc.cluster.local 10.10.0.1 为集群 kubernetes svc 解析ip Docker CE version 19.03.6 Kubernetes Version 1.18.2 Etcd Version v3.4

1 什么是external-traffic-policy 在k8s的Service对象（申明一条访问通道）中，有一个“externalTrafficPolicy”字段可以设置。有2个值可以设置：Cluster或者Local。 1）Cluster表示：流量可以转发到其他节点上的Pod。 2）Local表示：流量只发给本机的Pod。 图示一下： 2 这2种模式有什么区别 存在这2种模式的原因就是，当前节点的Kube-proxy在转发报文的时候，会不会保留原始访问者的IP。 2.1 选择（1）Cluster 注：这个是默认模式，Kube-proxy不管容器实例在哪，公平转发。 Kube-proxy转发时会替换掉报文的源IP。即：容器收的报文，源IP地址，已经被替换为上一个转发节点的了。 原因是Kube-proxy在做转发的时候，会做一次SNAT (source network address translation)，所以源IP变成了节点1的IP地址。 ps：snat确保回去的报文可以原路返回，不然回去的路径不一样，客户会认为非法报文的。（我发给张三的，怎么李四给我回应？丢弃！） 这种模式好处是负载均衡会比较好，因为无论容器实例怎么分布在多个节点上，它都会转发过去。当然，由于多了一次转发，性能会损失一丢丢。 2.2 选择（2）Local 这种情况下，只转发给本机的容器，绝不跨节点转发。