openstack k8s,k8s中创建ingress address 为什么是空
openstack k8s,k8s中创建ingress address 为什么是空详细介绍
本文目录一览： openstack和k8s的区别
OpenStack和K8s是2种不同的开源类软件类型，简单的说就是OpenStack面向资源层，改变的是资源供给模式；而K8s面向应用层，变革的是业务架构。
所以，使用容器且集群规模不大，直接用K8s就可以；集群规模大，不管应用是否只是跑在容器中，都是OpenStack＋K8s更好。
OpenStack＋K8s是各取所长，并不只是因为惯性，而是对于多租户需求来说，Container（容器）的隔离性还需要加强，需要加一层VM（虚拟机）来弥补，而OpenStack是很好的方案。
不过，VM＋Container的模式，必然有性能的损耗，所以OpenStack基金会也推出一个项目叫KataContainers，希望减少虚拟化的开销，兼顾容器的性能和隔离性。
OpenStack实现方案
1、OpenStack的网络分为flat、vlan、vxlan。
2、br-tun是vxlan的隧道，隧道id对应了对应vlan id的vlan二层。
3、br-int是添加vlan头、解vlan头的部分。
4、route是ovs虚拟出来的路由器，不同vlan对应不同网关，通过snat出外网。
5、浮动ip是ovs在虚拟路由器上dnat反向到vm的过程。
openstack和k8s区别是什么？
openstack是1化N，通过虚拟化的方式提供弹性灵活高利用率的计算能力。
hadoop是N化1，通过分布式文件系统提供强大的数据处理能力。
关于k8s使用ovs internal port的一些问题
openstack 的软路由，虚拟机port已经在用internal port来接入ovs bridge，而且在性能上确实比veth-pair有提升
ovs-internal-port 11.1-11.4Gb/s (1 process) 12.9-13.3Gb/s (4 process)
veth-pair-device 10.8-11.0Gb/s (1 process) 11.8-12.2Gb/s (4 process)
但是k8s获取pod ip的方式就是通过 eth0来获取的，这是一个硬编码。
这样就要求pod内部必须要有一个eth0网卡。
为了使用internal port，
可以先创建port，接入到br-int，（不同pod使用不同的port 名）
然后将该port设备，放入pod ns内部，并进行重命名。
那么问题来了，当创建新的port的时候，或者重启openvswitch。
已经配置好的port就会从pod ns内部移出。 这样就会导致网络问题。
如果不这样做，就需要采用两个网卡的方案，用原生port名直接放进去，配置好ip，然后弄一个dummy eth0网卡，也配上ip。
但是这个逻辑又过于复杂，pod内部多网卡也不够简洁。
结论： ovs 对internal 网卡的重命名支持的不够好。
https://github.com/antrea-io/antrea/issues/1691
K8s持久化存储
Volume 提供了非常好的数据持久化方案，不过在可管理性上还有不足。
要使用 Volume，Pod 必须事先知道如下信息：
Pod 通常是由应用的开发人员维护，而 Volume 则通常是由存储系统的管理员维护。开发人员要获得上面的信息：
要么询问管理员。
要么自己就是管理员。
这样就带来一个管理上的问题：应用开发人员和系统管理员的职责耦合在一起了。如果系统规模较小或者对于开发环境这样的情况还可以接受。但当集群规模变大，特别是对于生成环境，考虑到效率和安全性，这就成了必须要解决的问题。
Kubernetes 给出的解决方案是什么 PersistentVolume （PV）和 PersistentVolumeClaim（PVC）。
PersistentVolume (PV) 是外部存储系统中的一块存储空间，由管理员创建和维护。与 Volume 一样，PV 具有持久性，生命周期独立于 Pod。
PersistentVolumeClaim (PVC) 是对 PV 的申请 (Claim)。PVC 通常由普通用户创建和维护。需要为 Pod 分配存储资源时，用户可以创建一个 PVC，指明存储资源的容量大小和访问模式（比如只读）等信息，Kubernetes 查找并提供满足条件的 PV。
有了 PersistentVolumeClaim，用户只需要告诉 Kubernetes 需要什么样的存储资源，而不必关心真正的空间从哪里分配，如何访问等底层细节信息。这些 Storage Provider 的底层信息交给管理员来处理，只有管理员才应该关心创建 PersistentVolume 的细节信息。
1、配置nfs
需要安装
k8s-master：nfs-server
k8s-node1：nfs-client
k8s-node2：nfs-client
所有节点安装nfs
在master节点创建共享目录
编辑exports文件
启动rpc和nfs（注意顺序）
作为准备工作，我们已经在 k8s-master 节点上搭建了一个 NFS 服务器，目录为 /nfsdata：
2、创建PV
下面创建一个 PV mypv，配置文件 nfs-pv.yml 如下：
① capacity 指定 PV 的容量为 1G。
② accessModes 指定访问模式为 ReadWriteOnce，支持的访问模式有：
ReadWriteOnce：PV 能以 read-write 模式 mount 到单个节点。
ReadOnlyMany：PV 能以 read-only 模式 mount 到多个节点。
ReadWriteMany ：PV 能以 read-write 模式 mount 到多个节点。
③ persistentVolumeReclaimPolicy 指定当 PV 的回收策略为 Recycle，支持的策略有：
Retain： 需要管理员手工回收。
Recycle：清除 PV 中的数据，效果相当于执行 rm -rf /thevolume/*。
Delete： 删除 Storage Provider 上面的对应存储资源，例如 AWS EBS、GCE PD、Azure Disk、- OpenStack Cinder Volume 等。
④ storageClassName 指定 PV 的 class 为 nfs。相当于为 PV 设置了一个分类，PVC 可以指定 class 申请相应 class 的 PV。
⑤ 指定 PV 在 NFS 服务器上对应的目录。
创建 mypv：
STATUS 为 Available，表示 mypv 就绪，可以被 PVC 申请。
3、创建PVC
接下来创建 PVC mypvc，配置文件 nfs-pvc.yml 如下：
部署pvc
4、创建pod
上面已经创建好了pv和pvc，pod中直接使用这个pvc即可
与使用普通 Volume 的格式类似，在 volumes 中通过 persistentVolumeClaim 指定使用 mypvc 申请的 Volume。
通过命令创建mypod：
在这里，可以尝试在任何一方删除文件，文件在两端都会消失；
当 PV 不再需要时，可通过删除 PVC 回收。未删除pvc之前 pv的状态是Bound
删除pod
删除pvc
再次查看pv的状态
删除pvc之后pv的状态变为Available，，此时解除绑定后则可以被新的 PVC 申请。
/nfsdata文件中的文件被删除了
因为 PV 的回收策略设置为 Recycle，所以数据会被清除，
但这可能不是我们想要的结果。如果我们希望保留数据，可以将策略设置为 Retain
虽然 mypv 中的数据得到了保留，但其 PV 状态会一直处于 Released，不能被其他 PVC 申请。为了重新使用存储资源，可以删除并重新创建 mypv。删除操作只是删除了 PV 对象，存储空间中的数据并不会被删除。
PV 还支持 Delete 的回收策略，会删除 PV 在 Storage Provider 上对应存储空间。NFS 的 PV 不支持 Delete，支持 Delete 的 Provider 有 AWS EBS、GCE PD、Azure Disk、OpenStack Cinder Volume 等。
前面的例子中，我们提前创建了 PV，然后通过 PVC 申请 PV 并在 Pod 中使用，这种方式叫做静态供给（Static Provision）。
与之对应的是动态供给（Dynamical Provision），即如果没有满足 PVC 条件的 PV，会动态创建 PV。相比静态供给，动态供给有明显的优势：不需要提前创建 PV，减少了管理员的工作量，效率高。
基于NFS的PV动态供给(StorageClass)
静态：pod-->pvc-->pv
动态：pod -->pvc-->storageclass
去官网下载三个文件
这三个文件去网上下载 https://github.com/kubernetes-incubator/external-storage/tree/master/nfs-client/deploy
使用脚本批量下载：
其中deployment.yaml需要修改一下挂载的地址,目录,镜像版本
然后分别去应用这三个文件
创建pod进行测试
查看pv和pvc
在部署 statefulset 类型的工作负载时，动态创建 PV/PVC 是一种比较常用的配置方式，动态创建 PV/PVC 的方法基本如下：
一直启动不起来，查看 pvc 和 pods 信息如下：
从上边的现象来看，是 PVC 没有创建成功，动态 PVC 中，是 provisioner 中来负责创建，查看其日志，看到如下错误信息：
Google 之后，找到主要原因是，官方在 k8s 1.20 中基于对性能和统一 apiserver 调用方式的初衷，移除了对 SelfLink 的支持，而 nfs-provisioner 需要 SelfLink 该项功能。具体计划和原因可查看这个 issue[2] 和 KEP[3] 。
K3S 为兼容 K8S 应该也继承了该项修改，按 K8S 的方式修改测试了下，完美解决。
解决问题主要有下边两种方式：
1、修改 apiserver 的配置文件，重新启用 SelfLink 功能。针对 K8S，可添加如下配置：
K3S 中没有 apiserver 的配置文件，可通过 systemd 的启动文件添加该参数，如下：
若为新安装，可如下启用：
2、使用新的不基于 SelfLink 功能的 provisioner 镜像，重新创建 provisioner 容器。
若你能科学上网，可使用这个镜像：
国内可使用这个镜像【若不可用自己查找】：
k8s高可用部署：keepalived + haproxy
最近依照网上不少文章部署K8s高可用集群，遇到了一些麻烦，在这里记录下来。
根据K8s官方文档将HA拓扑分为两种，Stacked etcd topology（堆叠ETCD）和External etcd topology（外部ETCD）。 https://kubernetes.cn/docs/setup/production-environment/tools/kubeadm/ha-topology/#external-etcd-topology
堆叠ETCD : 每个master节点上运行一个apiserver和etcd, etcd只与本节点apiserver通信。
外部ETCD : etcd集群运行在单独的主机上，每个etcd都与apiserver节点通信。
官方文档主要是解决了高可用场景下apiserver与etcd集群的关系, 三master节点防止单点故障。但是集群对外访问接口不可能将三个apiserver都暴露出去，一个挂掉时还是不能自动切换到其他节点。官方文档只提到了一句“使用负载均衡器将apiserver暴露给工作程序节点”，而这恰恰是生产环境中需要解决的重点问题。
Notes: 此处的负载均衡器并不是kube-proxy，此处的Load Balancer是针对apiserver的。
下面以一个实验验证高可用性。准备三台机器以及一个vip（阿里云，openstack等都有提供）。
haproxy提供高可用性，负载均衡，基于TCP和HTTP的代理，支持数以万记的并发连接。 https://github.com/haproxy/haproxy haproxy可安装在主机上，也可使用docker容器实现。文本采用第二种。
创建配置文件/etc/haproxy/haproxy.cfg，重要部分以中文注释标出：
在三个节点启动haproxy
keepalived是以VRRP(虚拟路由冗余协议)协议为基础, 包括一个master和多个backup。 master劫持vip对外提供服务。master发送组播，backup节点收不到vrrp包时认为master宕机，此时选出剩余优先级最高的节点作为新的master, 劫持vip。keepalived是保证高可用的重要组件。
keepalived可安装在主机上，也可使用docker容器实现。文本采用第二种。( https://github.com/osixia/docker-keepalived )
配置keepalived.conf, 重要部分以中文注释标出：
启动keepalived:
查看keepalived master容器日志：
查看master vip:
可以看到vip已绑定到keepalived master
下面进行破坏性测试：
暂停keepalived master节点haproxy
查看keepalived master日志
可以看到haproxy检测失败，priority降低，同时另一节点10.53.61.195 priority 比master节点高，master置为backup
查看10.53.61.195 keepalived日志：
可以看到10.53.61.195被选举为新的master。
至此高可用实验完成，接下来就是使用kubeadm安装k8s组件，这里就不展开了。
K8s暴露内部服务的多种方式
测试yaml：
测试yaml：
端口转发利用的是Socat的功能，这是个神奇的工具，你值得拥有： Socat
之前都是直接将pod上的应用暴露出去，这种方式在实际的生产环境中基本不可取，标准的搞法是基于Service。
Service有三种类型：ClusterIP、NodePort、LoadBalancer。
首先，先了解下Service中端口的概念：
port/nodeport/targetport
port ——Service暴露在Cluster IP上的端口，也就是虚拟IP要绑定的端口。port是提供给集群内部客户端访问Service的入口。
nodeport ——K8s集群暴露给集群外部客户访问Service的入口。
targetport ——是Pod内容器的端口。从port和nodeport上进入的数据最终会经过Kube-proxy流入到后端pod里容器的端口，如果targetport没有显示声明，那么会默认转发到Service接受请求的端口（和port端口保持一致）。
通过Service暴露内部服务的方式有四种：ClusterIP、NodePort、LoadBalancer、Ingress
ClusterIP其实是Service的缺省类型，就是默认类型，例如之前部署的dashboard插件其实就使用是这种类型，可以通过如下指令来分辨：
所以，这种类型的Service本身是不会对集群外暴露服务的，但是却单单可以通过K8s Proxy API来访问。Proxy API是一种特殊的API，Kube-APIServer只代理这类API的HTTP请求，然后将请求转发到某个节点上的Kubelet进程监听的端口上，最后有该端口上的REST API响应请求。
在集群外部访问，需要借助于kubectl，所以集群外的节点必须配置了经过认证的kubectl，可以参看kubectl的配置章节：
这种方式要求访问节点必须具备受认证的kubectl，所以只能用做调试使用。
NodePort是基于ClusterIP的方式来暴露服务的，不过不需要kubectl的配置，他是在每一个node上都监听同一个端口，该端口的访问都会被引导到Service的ClusterIP，后续的方式和ClusterIP的方式是一样的，例子如下：
访问nodeIP:NodePort的时候出现了pod所在的node是OK的，其他的Node访问被拒绝,原因和Docker的版本有关，参看 kubernets nodeport 无法访问 ，解决方案就是在其他的Node上修改FORWARD的链生成规则：
这样就可以访问了：
只能在Service上定义，LoadBalancer是一些特定公有云提供的负载均衡器，需要特定的云服务商提供，比如：AWS、Azure、OpenStack 和 GCE (Google Container Engine) 。这里略过不谈。
与之前的暴露集群Service的方式都不同，Ingress其实不是一种服务。它位于多个服务之前，充当集群中的智能路由器或入口点。类似于Nginx提供的反向代理，其实官方推荐的方式就是Nginx的实现方式。这里以Nginx-Ingress的思路来构建。
Ingress的功能需要两个部分组成，一个是Nginx做网络的7层路由，一个是Ingress-controller来监听ingress rule的变化实时更新nginx的配置，所以在k8s的集群里为了实现Ingress都必须要部署一个Ingress-controller的pod，可以使用官网的套路：
到这一步，Ingress的集群配置已经做完了，接下来进行测试，通过Ingress暴露两个内部的Nginx服务：
然后，给这两个服务配置Ingress规则：
k8s中创建ingress address 为什么是空
k8s来源于Google生产环境的实践，社区活跃度很高，在github上的Star数17k+，30k+commits，同时由Google主导CNCF基金会也在强力运作k8s的社区发展，也就在几个月前OpenStack社区宣布全面拥抱k8s，这也宣布了全球第大的开源IAAS云社区已经选择k8s作为容器的唯一解决方案。
如果保证自己的集群环境没问题的话，分两种情况：
1、集群是用kubeadm自己搭建的，目前kubeadm这种集群搭建的有些能力还不匹配，先检查自己的service是否有external-ip，如果没有需要手动配置一个；然后这时候重新部署ingress应该就有ip了。
2、如果是云平台托管的集群，最好提工单，由云平台的技术人员帮忙排查。
谢谢，希望能帮到你。
云计算2020展望（技术篇）：Serverless、K8s、服务网格、OSS、HPC
回顾2019年中国云计算产业的发展，趁着“产业互联网”火热的东风，云计算也一路高歌前行。阿里巴巴、腾讯、百度、华为等 科技 互联网巨头企业都在持续布局。
Salesforce与阿里巴巴达成战略合作，阿里巴巴推出政务钉钉，百度云升级为百度智能云，百度推出爱番番CRM开放平台，销售易获腾讯独家1.2亿美元E轮融资，腾讯云全面升级弹性计算产品序列，计算性能提升30%；金山办公正式登陆科创板上市、华为新成立“华为云计算技术有限公司” ……这些“新鲜“的云计算故事，也都曾轰动一时，甚至时至今日，仍对云计算领域影响至深。
2020年刚起步，中国云计算“第一股”——UCloud成功登陆科创板，成为众多业内人士在武汉的新型冠状病毒肺炎爆发前，最关注的"热点”之一。
展望2020年，亿欧智库坚定看好云计算领域的发展机会，并将持续输出云计算产业细分领域，如PaaS、SaaS、云安全等领域的研究报告。
值得注意的是，亿欧智库此前发布的《2019年中国云计算行业发展研究报告》所总结的六条云计算产业发展趋势依旧具备长期预判价值。以下列出概括性的内容，具体详见报告正文：
基于此，亿欧智库进一步总结云计算产业的未来发展趋势，帮助业内人士更加及时把握云计算产业最新发展机遇。本篇将重点介绍五条云计算产业有希望快速落地或爆发的主流技术：
无服务器计算（Severless Computing，以下简称Serverless）是一种包含第三方BaaS（后端即服务）服务的应用程序设计方式，与包括FaaS（函数即服务）平台上的托管临时容器中运行的自定义代码。与很多技术趋势一样，Serverless至今还没有明确且清晰的定义，对于开发人员来说，其重点代表两个截然不同但有重合的概念：
Serverless相比IaaS和SaaS，可以更好更快的在云服务商平台上部署应用，完全不用提前测算资源需求，所有功能根据事件驱动，按需加载，执行完毕，资源释放，真正实现了用多少付费多少，降低成本的同时，还提高了开发人员的生产力。
Serverless主要适合于新兴的、事件驱动性的，类似于IoT等传感设备、金融交易类型等场景。
Serverless兴起于2017年，在最近两年伴随云原生概念的推广逐渐火热。
目前 Serverless 在国内的发展和采用依然处于初期阶段，业务实践偏少，仍在不断 探索 之中。相比之下，国外整体要领先 1-2 年，国外几大云厂商前期对整个研发生态的教育和布局较多，应用较早。
现在国外也已经出现不少 Serverless 框架，比较知名包括 Serverless.com 和 Zeit.com。
根据RightScale的2018年云状态报告，无服务器是当今增长速度很快的云服务模型，年增塑达75%，并有望于2020年超越该增速。亿欧智库也对Serverless的增长速度和市场规模持乐观态度。
Kubernetes（以下简称K8s） 是一个针对容器应用，进行自动部署，弹性伸缩，和管理的开源系统。主要负责在大规模服务器环境中管理容器组（pod）的扩展、复制、 健康 ，并解决 pod 的启动、负载均衡等问题。
K8s 能在实体机或虚拟机集群上调度和运行程序容器。K8s 也能让开发者斩断联系着实体机或虚拟机的“锁链”，从以主机为中心的架构跃至以容器为中心的架构。该架构最终提供给开发者诸多内在的优势，例如可移动、可扩展、自修复等。
K8s 也能兼容各种云服务提供商，例如 Google Cloud、Amazon、Microsoft Azure，还可以工作在 CloudStack、OpenStack、OVirt、Photon、VSphere。
K8s 源于 Google 内部的 Borg 项目，经 Google 使用 Go 语言重写后，被命名为Kubernetes，并于 2014 年 6 月开源。目前已有多家大公司，例如 Microsoft、 RedHat、 IBM、Docker，都支持K8s。
从近年来国外K8s发展来看， 巨头公司为自有K8s部门增添活力或构建全新产品的有效手段之一为收购 。
随着专注于容器初创公司逐渐增加，预计2020年各大云服务商将继续收购表现优秀的容器初创公司，以进军K8s市场，完善其产品体系。
不可否认，K8s作为一项新兴技术距全球普及它还有很长的路要走。但很明显，K8s已经是，并且将继续是软件世界中的主导力量。
服务网格（Service Mesh）是用于控制和监视微服务应用程序中的内部服务到服务流量的软件基础结构层。服务网格的独特之处在于它是为适应分布式微服务环境而构建的。
服务网格的兴起主要是为了解决Docker和Kubernetes无法解决的运行问题。因为诸如Docker和Kubernetes这样的工具主要解决的是部署的问题。但部署不是生产的最后一步，部署完之后，应用程序还必须运行，服务网格因解决运行问题应运而生。
2016年服务网格提出之后，以Linkerd和Envoy为代表的框架开始崭露头角。目前市面上没有现成的商业产品，大多数服务网格都是开源项目，需要一些技巧才能实现。最著名的有：
关于服务网格技术的并购目前也逐渐升温，著名的并购案有VMware在2019年7月以4.2亿美元收购了Avi Networks以及F5 Networks在2019年5月斥资2.5亿美元收购了NGINX。
2019年是被确定是适合解决服务网格问题的一年，2020年将会是核心服务网格用例出现的一年。
开源软件（Open Source Software，以下简称OSS）被定义为描述其源码可以被公众使用的软件，并且此软件的使用，修改和分发也不受许可证的限制。
1998年2月，“开源”一词首先被运用于软件。最初的开源软件项目并不是真正的企业，而是一些顶级程序员针对Microsoft、Oracle、SAP等老牌闭源公司对软件收费较高的一场革命。顶级开发人员通常以异步方式协同编写一些出色的软件。每个人不仅可以查看公开的软件，而且通过一种松散的治理模型，他们可以添加，改进和增强它。这是第一代的开源软件项目。
而经过10多年的发展，Linux、MySQL的成功为第二代开源软件公司奠定基础，比如Cloudera和Hortonworks。但第二代开源软件公司中，没有一家公司对软件拥有绝对的控制权，对手经常通过免费提供软件来进行竞争。
之后出现了像Elastic、Mongo和Confluent等第三代开源软件公司提供的Elastic Cloud，Confluent Cloud和MongoDB Atlas这样的服务，这种进化代表着开源软件公司这种模式有机会成为软件基础设施的主要商业模式。
经过22年的发展，如今OSS已经无处不在。OSS领域也发声了一些“大事件”：IBM以320亿美元的价格收购了Redhat（是2014年市值的3倍）；Mulesoft在上市后以65亿美金的价格被Salesforce收购；MongoDB现在市值超过40亿美元；Elastic则为60亿美元；并且，通过Cloudera和Hortonworks的合并，将出现一个市值超过40亿美元的新公司……
当然还有很多OSS的公司在路上，例如Confluent、HashiCorp、DataBricks、Kong、Cockroach Labs等。
展望2020年，OSS的理念将与云计算SaaS（软件即服务）的理念更加契合，将大大推动软件产业的创新，并有机会迎来新一轮的发展高潮。
高性能计算（High Performance Computing，以下简称HPC）指能够执行一般个人电脑无法处理的大资料量与高速运算的电脑，其基本组成组件与个人电脑的概念无太大差异，但规格与性能则强大许多。
HPC能够在非常短的时间内执行大量计算，正从过去主要传统科研领域计算密集型为主，逐渐向新兴的大数据、人工智能以及深度学习等方向进行融合和演进。
从应用领域来看，HPC是不同行业中非常专业的领域，可以用于预报天气，也可以是分析风险，还可以分析农场数据，以根据不断变化的天气条件找到最佳的农作物种植地点。
在中国市场当中，主要有联想、浪潮和曙光三家公司处于领先的地位，占据了超过90%的市场份额。这三家公司作为中国HPC市场的状元、榜眼和探花，共同将中国HPC推上了世界第一的位置。
其中，联想连续五年蝉联“HPC China TOP100榜单”第一名，并于2019年11月8日发布“深腾X9000”高性能融合计算平台，该平台在兼顾算的更快、更准、更全面的同时，也使联想成为HPC绿色数据中心的积极倡导者，继续领跑HPC水冷解决方案。
除此之外，联想还在全球160多个国家开展众多领域的突破性研究，这些领域包括癌症、大脑研究、天体物理学、人工智能、气候科学、化学、生物学、 汽车 和航空等。
公开调研资料显示，2018年企业中使用了HPC的比例是36%。随着云计算领域的基础设施完备、资源和数据的增加，HPC的需求也将在2020年有所增加，云服务商有望对HPC进行投资。
众所周知，技术的进步对产业发展和创新具有积极推动作用。
正如近年来区块链、5G、机器学习等技术的发展对传统产业的转型促进一样，Serverless、Service Mesh、K8s、OSS、HPC这些云技术也必将提升IaaS、PaaS、SaaS等传统云计算模式的弹性、灵活性、计算能力等，并与传统模式融合互补，协同助推各产业转型升级。
推荐阅读：
千淘万漉，吹尽黄沙，中国智能制造哨声洪亮 | 预见2020
2020银行业展望：对外开放加快，理财转型提速， 科技 深度赋能……
2020物流业新态势：巨头效应显著、 科技 赋能、智慧物流建设加快……
拨云见日，始得真金，产业互联网迎来高光时刻丨预见2020
预见2020：日新月异的中国保险业
201207：SVN提示文件被锁定不能更新-什么是k8s
首先想到的是可以使用svn客户端本身的svn clean up来解决这个问题，在你不能更新的目录右键执行；
如果不成功，那就不是本目录锁定，系统提示上一层目录锁定，需要到上一层或者根目录中清除；
如果在根目录下都无法clean的话，一般采取的方法删除现有的目录，重新CHECKOUT，此步骤，一定要注意自己已修改待提交的文件的备份，要不努力就付诸东流了；
当然，在网上找到了比较省事的方法：
其实SVN加锁会在.SVN（隐藏文件）中生成一个名字叫lock的文件（无后缀），查找所有的，手工删除。然后再尝试更新，系统可能会提示某个.base文件无法访问。找到它，把相关的文件或其所在的目录删除，重新UPDATE。
k8s全称kubernetes，这个名字大家应该都不陌生，k8s是为容器服务而生的一个可移植容器的编排管理工具，越来越多的公司正在拥抱k8s，并且当前k8s已经主导了云业务流程，推动了微服务架构等热门技术的普及和落地，正在如火如荼的发展。那么称霸容器领域的k8s究竟是有什么魔力呢？
首先，我们从容器技术谈起，在容器技术之前，大家开发用虚拟机比较多，比如vmware和openstack，我们可以使用虚拟机在我们的操作系统中模拟出多台子电脑（Linux），子电脑之间是相互隔离的，但是虚拟机对于开发和运维人员而言，存在启动慢，占用空间大，不易迁移的缺点。举一个我亲身经历过的场景吧，之前在vmware中开发了一个线下平台，为了保证每次能够顺利使用，我们就把这个虚拟机导出为OVF，然后随身携带，用的时候在服务器中部署，这里就充分体现了虚拟机的缺点。
接着，容器化技术应运而生，它不需要虚拟出整个操作系统，只需要虚拟一个小规模的环境即可，而且启动速度很快，除了运行其中应用以外，基本不消耗额外的系统资源。Docker是应用最为广泛的容器技术，通过打包镜像，启动容器来创建一个服务。但是随着应用越来越复杂，容器的数量也越来越多，由此衍生了管理运维容器的重大问题，而且随着云计算的发展，云端最大的挑战，容器在漂移。在此业务驱动下，k8s问世，提出了一套全新的基于容器技术的分布式架构领先方案，在整个容器技术领域的发展是一个重大突破与创新。
那么，K8S实现了什么？
从架构设计层面，我们关注的可用性，伸缩性都可以结合k8s得到很好的解决，如果你想使用微服务架构，搭配k8s，真的是完美，再从部署运维层面，服务部署，服务监控，应用扩容和故障处理，k8s都提供了很好的解决方案。
具体来说，主要包括以下几点：
总而言之，k8s可以使我们应用的部署和运维更加方便。
k8s集群由Master节点和Node（Worker）节点组成。
Master节点
Master节点指的是集群控制节点，管理和控制整个集群，基本上k8s的所有控制命令都发给它，它负责具体的执行过程。在Master上主要运行着：
Node节点
除了master以外的节点被称为Node或者Worker节点，可以在master中使用命令 kubectl get nodes 查看集群中的node节点。每个Node都会被Master分配一些工作负载（Docker容器），当某个Node宕机时，该节点上的工作负载就会被Master自动转移到其它节点上。在Node上主要运行着：
运维需要学什么
岗位职责：
1、负责公司网络总体系统及子系统的维护；
2、负责网络整体架构规划、实施、优化、安全；
3、负责整体网络的操作规范文档编写，整合系统资源；
4、负责整体网络的风险评估与备份系统实现；
5、研究主流的互联网应用技术，并负责将此是现在公司业务系统测试及应用；
6、公司整体网络架构规划，实施及维护；
7、主动发现问题，提出合理化建设，积极提出优化手段和建议。
一、Linux 基础部分
1、基础理论知识
2、基础命令（系统命令、目录管理、用户管理、文件权限、磁盘管理、资源查看等等常见操作）
3、文本高效处理（vi、vim、awk、grep、find、sed等）
4、bash shell脚本（可以边工作边学习,使用shell编写简单的代替重复性操作的脚本）
5. 进程调度，内存管理，文件系统，外设管理等，要熟练使用相关工具，如top iotop iftop iostat vmstat ss等，并且最好了解其原理
二、网络管理、进程管理
1、TCP/IP协议、DNS服务、CDN原理、iproute常见的网络客户端工具（ping、wget、ftp）
2、crontab计划任务
3、ps、top、htop、vmstat、lsof等命令
4. tcp，http，https，udp等
5. 最好能做到精通，4层，7层的网络流量分析技能要熟练掌握。
6. 内部路由协议，边际路由，交换原理，域名解析，ipv6相关知识
三. 数据库部分
MySQL各个版本之间的关系和特性
MySQL的安装及增删改查
MySQL的存储引擎
MySQL的优化
MySQL日常使用及运维，包含备份及故障排查
四. 常用开源组件
LAMP和LNMP的架构
tomcat的使用及优化
nginx的使用场景及优化
apache的使用场景及优化
其他服务： dhcp,nfs,rsync,dns,等等
一句话概括： mysql，redis，kafka，etcd，zk，influxdb，promethues，zabbix，graphana，ansible…
五. shell脚本
使用shell脚本实现各种服务的自动化部署
使用shell脚本实现监控系统及应用自动化
使用shell脚本实现各类巡检，故障排查自动化
六. 安全
iptables四表（fiter、mangle、nat、raw）五链（prerouting、iput、forward、output、postrouting）、基本匹配
iptable规则保存重载生效
常用加密算法，web安全，网络安全
渗透的常用手段，以及反制手段，sql注入，xss，ddos，cc
跳板机jumpserver
七. 监控和日志收集
日志收集ELK,EFK
zabbix，prometheus
八. 自动化工具
1、常见自动化运维方案：puppet、ansible、salt、fabric
2、ansible安装基础使用
3、持续集成：jekins+gitlab实现ci/cd流水线
4. python 自动化
5. go语言二次开发
九. 容器化和虚拟化技术
docker ，k8s，openstack， kvm，vmware的使用
容器编排的技术
十. devops 编译，加速，测试环境，研发自动化
运维工程师一般有系统运维、网络运维、运维开发、数据库运维、云运维等方向，今天主要介绍系统运维工程师所需要具备的一些技能和考证方面。
系统运维工程师必备技能
系统运维工程师不仅需要有Linux基本操作技能，还应该会服务器硬件、以及企业里常用的双机集群、Windows、VMware、数据库等技能，这样才能有担任合格的系统运维工程师。
需要特别注意企业里物理机都是用双机集群，一定要掌握双机集群的技能，包括Linux双机集群、Windows双机集群、Oracle Rac数据库集群、SQL Server数据库集群等。