从前面的文章我们知道，Kubernetes 脱胎于 Google 的 Borg，Borg 在 Kubernetes 诞生之初已经在 Google 内部身经百战 10 余年，且不说它的历史源远流长，就凭它是出自 Google 那帮天才工程师之手，就知道它的学习难度不低。
[381412-20190709182042280-2033777895.png]
如果读者按照前面的流程建好了服务，那么应该会有一个问题困扰，如何访问这个nginx服务呢？
最近玩Discourse论坛程序，由于资源消耗过于严重，这个月主机崩了好几次，我打算配合frp内网穿透，把个人服务器做成主从分布的架构，为了便于管理， 我选择采用目前最流行的k8s集群管理技术，对已有服务进行集群式管理，今天先本地Ubuntu20.04搭建一个单机版k8s，也就是minikube，试一下水。
minikube 是一个虚拟机，启动后会在内部自动创建一个 k8s 集群。minikube 是 k8s 的 node。
K8S 如火如荼的发展着，越来越多人想学习和了解 K8S，但是由于 K8S 的入门曲线较高很多人望而却步。 然而随着 K8S 生态的蓬勃发展，社区也呈现了越来越多的部署方案，对于生产环境就有好几种部署方案，对于测试、学习环境也同样衍生出了好几种方式。
之前我们简单的了解一下 k8s 中 service 的玩法，今天我们来分享一下 service 涉及到的相关细节，我们开始吧
OpenShift的OVS网络组件有三种模式：ovs-subnet、ovs-multitenant、ovs-networkpolicy。
前言 本文仅代表作者魏新宇的个人观点；在书写过程中，笔者与同事郭跃军进行了技术讨论，大有裨益，在此表示感谢！ 一、K8S vs OCP, 网络端口访问方式 我在上一篇文章《深度理解：Openshif
容器不是模拟一个完整的操作系统，而是对进程进行隔离，对容器里的进程来说它接触到的各种资源都是独享的，比虚拟机启动快、占用资源少。
Service 是 k8s 网络部分的核心概念，在 k8s 中，Service 主要担任了四层负载均衡的职责。本文从负载均衡、外网访问、DNS 服务的搭建及 Ingress 七层路由机制等方面，讲解 k8s 的网络相关原理。
描述: K8s中的Service实际上是微服务框架中的微服务，Service定义了一个服务的访问入口，可以通过该入口访问其背后一组的有Pod副本组成的集群实例;
//这里使用的dashboard版本较高，相较于之前的版本访问必须使用火狐浏览器，这里不需要。
在之前文章中我们介绍了基于iptable方式实现的k8s集群中cluster ip类型和node port类型service的负载均衡。其本质上是当网络数据包从pod的network namespace中通过linux veth pair设备进入到host宿主中的network namespace时，经过iptable一系列的NAT转换，把service的cluster ip和端口DNAT成pod的ip和端口。同时leverage linux iptable的random模块，实现了对pod的负载均衡，然后再交由host对目标pod的路由策略来实现将数据包发往pod。当然，这一切都是在linux内核空间实现的，和应用程序的用户空间没有关系。在这里我们主要介绍基于ipvs的cluster ip类型service的实现原理。如果对于ipvs不熟悉的同学可以浏览一下网站http://www.linuxvirtualserver.org/，大名鼎鼎的LVS负载均衡就是基于ipvs来实现的。
在前面几篇文章中，我们学习了 kubeadm 、kubectl 的一些命令，也学会了 Deployment、Service、ReplicaSet 的用法以及配置。本篇的内容主要是介绍如何配置网络，使得能够在外部网络访问集群。
docker技术依赖于linux内核虚拟化技术的发展，对linux内核特性有很强依赖。docker用到的linux技术包括：
但是组成这么一整套的资源比较大，不利于个人安装学习。所以本文就介绍在只有k8s集群的环境下部署java项目到容器环境中。
k8s 我们已经从 NameSpace、Pod、PodController到Volumn都介绍过了，相信看完的小伙伴们也会很有收获的~那么今天我们继续来到k8s的课堂，这节我们将要来说下 k8S 搭建完服务后如何访问！
kubernetes 从一发布开始其学习门槛就比较高，首先就是部署难，用户要想学习 kubernetes 必须要过部署这一关，社区也推出了多个部署工具帮助简化集群的部署，社区中推出的部署工具主要目标有两大类，部署测试环境与生产环境，本节主要讲述测试环境的部署，目前社区已经有多套部署方案了：
Kubernetes中的Service是一种网络抽象，用于将一组Pod暴露给其他组件，例如其他Pod或外部用户。Service可以作为一个负载均衡器，为一组Pod提供单一的IP地址和DNS名称，并通过选择器来将流量路由到这些Pod。
因为前边K8S安装的是V1.23版本，所以这里需要选择能与V1.23的K8S兼容的dashboard版本。从页面上可以找到能兼容的dashboard最新的版本为V2.5.1。
打开这篇文章的同学，想必对 docker 都不会陌生。docker 是一种虚拟容器技术，它上手比较简单，只需在宿主机上起一个 docker engine，然后就能愉快的玩耍了，如：拉镜像、起容器、挂载数据、映射端口等等。
背景 随着容器、微服务、持续交付等云原生技术普及，大量应用基于K8s容器编排构建。相比传统网络模式，在云原生场景下，存在大量微服务模块间网络调用，集群内东西向通信流量激增，网络边界变得更加模糊。 容器环境中，容器IP和端口变换频繁，应用混合部署带来的通信关系复杂，传统基于静态IP和端口的边界安全规则已无法适用容器环境下细粒度的访问控制要求。默认情况下，K8s集群中不对Pod进行任何请求限制，任意Pod之间可以自由通信。正因此，在面对网络攻击时，没有安全规则的容器网络将给攻击者更多的自由和渗透空间。 如何实施
上一篇简单介绍了一下k8s是什么以及如何使用kubeadm快捷安装，今儿来聊一下k8s的几个基础概念及术语。k8s中的资源都可以使用yaml文件进行描述。（文章内容来源于《kubernetes权威指南 第四版》）
命令的方式创建资源，理解命令运行之后的动作，通过查看资源的方式，总结Pod名称的由来
是故不应取法，不应取非法。以是义故，如来常说：汝等比丘，知我说法，如筏喻者，法尚应舍何况非法。 ----------《金刚经》
就绪探针，用来判断 pod 是否就绪，就绪状态时service才会分发流量给该pod。
本篇文章适合k8s入门参考，使用 yaml 文件和 kubectl 命令完成应用部署。本文的脚本只演示了最基础的配置。
在上一个小系列文章《ASP.NET Core on K8S学习初探》中，通过在Windows上通过Docker for Windows搭建了一个单节点的K8S环境，并初步尝试将ASP.NET Core WebAPI项目部署到了K8S，把玩了一下快速部署和实例伸缩。这个系列开始，会继续学习K8S以及在Linux上搭建集群来深入把玩。本篇会回顾一下K8S的基本概念以及架构组成，然后会通过Kubeadm快速地搭建一个K8S集群供后续学习把玩之用。
在k8s中，我们的应用会以pod的形式被调度到各个node节点上，在设计集群如何处理容器之间的网络时是一个不小的挑战，今天我们会从pod（应用）通信来展开关于k8s网络的讨论。
相信使用过K8S或容器化的大家都有了解过私有容器仓库Harbor，Harbor是VMware大佬开源的一个私有容器镜像仓库，VMware也开源了另外一个工具就是本文要说到的Octant，从笔者的角度上看来它更像一个Dashboard的代替品。
当新手刚学习k8s时候，会被各种的IP 和port 搞晕，其实它们都与k8s service的访问有密切关系，梳理它们之间的差异可以更好了解k8s的服务访问机制。
在Kubernetes中，服务和Pod的IP地址仅可以在集群网络内部使用，对于集群外的应用是不可见的。为了使外部的应用能够访问集群内的服务，在Kubernetes中目前提供了以下几种方案：
分享一个大牛的人工智能教程。零基础！通俗易懂！风趣幽默！希望你也加入到人工智能的队伍中来！请点击http://www.captainbed.net
在上一篇《单节点环境搭建》中，通过Docker for Windows在Windows开发机中搭建了一个单节点的K8S环境，接下来就是动人心弦的部署ASP.NET Core API到K8S了。但是，在部署之前，我还是把基本的一些概念快速地简单地不求甚解地过一下。
BorgMaster:负责请求分发,整个集群的大脑 BorgLet:真正运行的节点,提供计算 sheduler:调度器,将数据写入到Paxos(键值对数据库)BorgLet监听Paxos数据库,如果发现有自己的请求则处理相应的任务
Service是k8s的核心，通过创建Service，可以为一组具有相同功能的容器应用提供一个统一的入口地址，并将请求进行负载分发到各个容器应用上。
Kubernetes Pod 是有生命周期的，它们可以被创建，也可以被销毁，然而一旦被销毁生命就永远结束。 通过 ReplicationController 能够动态地创建和销毁 Pod（例如，需要进行扩缩容，或者执行）。 每个 滚动升级 Pod 都会获取它自己的 IP 地址，即使这些 IP 地址不总是稳定可依赖的。 这会导致一个问题：在 Kubernetes 集群中，如果一组 Pod（称为 backend）为其它 Pod （称为 frontend）提供服务，那么那些 frontend 该如何发现，并连接到这组 Pod 中的哪些 backend 呢？
在本文中，我们将简单了解k3d，这是一款可让您在安装了Docker的任何地方运行一次性Kubernetes集群的工具，此外在本文中我们还将探讨在使用k3d中可能会出现的一切问题。
最近容器化部署服务非常火，以至于各个公司都在积极部署docker服务，今天介绍下Kubernetes，小强作为入门级选手，这是一篇 Kubernetes 的概览。
使用 K8s 的原生命令 kubectl部署一个web应用的镜像到 k8s 集群中，并通过 Ingress 将部署的服务暴露出来由外部访问。
本文将使用k8s部署一个springboot+redis应用，由于是示例，所以功能比较简单，只有设置值和获取值两个api。
在Kubernetes中排查故障是一个常见但有时复杂的任务，因为它涉及到多个层次的组件和服务。以下是常用的方式和方法，可以帮排查Kubernetes中的故障：
摘要：本文整理自集度汽车数据部门实时方向负责人、 Apache Flink Contributor 周磊&集度汽车数据开发专家顾云，在 FFA 2022 行业案例专场的分享。本篇内容主要分为四个部分：
文章的名字起的有点纠结，实际上这是一篇真正从基础开始讲解，并试图串联起来现有一些流行技术的入门文章。 目前的企业级运营市场，很有点早几年前端工程师所面临的那样的窘境。一方面大量令人兴奋的新技术新方案层出不穷；另外一方面运维人员也往往陷入了选择困局，艰于决策也疲惫于跟踪技术的发展。 目前的网络上已经有很多新技术的介绍文章和培训资料——绝大多数讲的比我要好得多。 因为工作原因，我有比较多的用户服务经验。所以我要说的是，写这篇文章的原因，不是因为现有资料不够好。而是这些资料大多都是从技术本身出发，不断的说“我可以提供A、我可以提供B、还有我的特征C也不错”。而忘记了问，用户想要的是什么，用户想解决的问题是什么。 所以不同于通常的技术文章使用技术本身串起来所有的内容，本文试图通过需求和技术的互动发展来串起来运维技术的发展历程。 在整体系统中，开发和运维都是很重要的，所以现在DevOps的理念早已深入人心。但本文并不讲解开发部分的内容，这里只集注在运维架构的演进方面。 即便如此，运维也是非常大的一个话题，所以我的目标再缩小一些，只限定在基础系统软件的领域。
本篇已加入《.NET Core on K8S学习实践系列文章索引》，可以点击查看更多容器化技术相关系列文章。
Ingress 英文翻译 进入;进入权;进食，更准确的讲就是入口，即外部流量进入k8s集群必经之口。这到大门到底有什么作用？我们如何使用Ingress？k8s又是如何进行服务发现的呢？先看一张图：
浅入Kubernetes(8)：外网访问集群 中已经介绍过部署一个 Deployment 和 Service，本篇是它的补充，将会广泛地聊一下 Service。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
对象存储
即时通信 IM
