前言：
公司算是很早一批使用k8s（kubernetes）的那一群，印象中是17年下半年就开始使用，也算是kubernetes使用的先驱之一了，从刚开始认识k8s到现在使用接近2年，陆陆续续从入门学习，到现在玩的还算溜，也踩过N多坑，血泪史也是一篇接一篇的，虽然用了两年多，公司很多人还是不太了解这个东西到底是啥，于是乎，在领导推动下，我写了一篇基础的关于kubernetes的介绍，事先说明，此文技术干货很少，大多数是理论介绍（虽然网上资料很多，我也算是收集了一下。），尽量用简单明了的方式去介绍这个大杀器，最后会有一点点的常用命令介绍，再重申一遍，这里没有具体的技术干货，部署什么的，网上文档很多，此处不会做细致描写。（当然，如果是大牛愿意跟我讨论k8s还是很欢迎，毕竟我还是菜鸟）
什么是kubernetes：
kubernetes，简称K8s，是用8代替8个字符“ubernete”而成的缩写。是一个开源的，用于管理云平台中多个主机上的容器化的应用，Kubernetes的目标是让部署容器化的应用简单并且高效（powerful）,Kubernetes提供了应用部署，规划，更新，维护的一种机制‘’通过部署容器方式实现，每个容器之间互相隔离，每个容器有自己的文件系统 ，容器之间进程不会相互影响，能区分计算资源。 Kubernetes最早是Google开源的一个容器编排引擎，它的前身是谷歌内部研发的Borg系统以及后来的Omega，它支持自动化部署、大规模可伸缩、应用容器化管理。在生产环境中部署一个应用程序时，通常要部署该应用的多个实例以便对应用请求进行负载均衡。 在Kubernetes中，我们可以创建多个容器，每个容器里面运行一个应用实例，然后通过内置的负载均衡策略，实现对这一组应用实例的管理、发现、访问，而这些细节都不需要运维人员去进行复杂的手工配置和处理。
以上总结下，kubernetes是基于容器化并且集成了部署，规划，更新，维护为一体的生产级的编排应用架构。kubernetes的各种支持是非常好的，支持自动化部署，自动弹性伸缩，应用容器化管理。另外kubernetes对语言的亲和性也很好，几乎所有语言都可以跑在kubernetes的容器集群里，kubernetes更多的是让人注重于应用层面的变化，而不是更多的关注于底层。
kubernetes内部组件简单介绍以及服务发现机制：
在介绍k8s内部组件之前，我希望看到我这篇文章的朋友，一定要抛弃一个概念，虽然k8s的节点概念是存在的，但是不要去想节点，底层所有节点其实是给k8s集群提供资源的，如果还用传统运维的思想去看节点的话，是很难弄懂k8s的机制的。虽然这个理解是我个人的想法，但是我还是希望能给看到文章的朋友一定的帮助。下面我会用我个人理解的方式来介绍一下k8s的组件，因为个人所学有限，如果有错误的地方欢迎指出。
kubectl--k8s命令的发布者：我们管理整个k8s集群的时候，需要各种命令，在master节点或者管理节点上，kubectl就是这个命令的发布者，观察集群，操控集群，部署等等，都是依赖于这个命令来完成的。
APIServer--k8s集群的通信枢纽 ： API这个概念现在应该都不陌生，在k8s集群里，所有的命令下达，甚至是管理节点的信息传达变更等等都需要这个组件进行信息的传达，如果他挂了。集群整个都会失联。
etcd--k8s数据的存储者： k8s核心组件之一，有国内大牛参与的项目，这个可以单独拎出来做个集群，基于key-value模式进行数据存储，整个集群的信息，变更，规则，都是存储在他这里。
Controller Manager--k8s资源管理者、控制者： 整个节点的资源的管理，控制都是靠这个组件，它会对整个节点的资源进行一个观察和反馈，甚至于pod的生存周期都受它的控制，生杀大权的掌控者。
Scheduler--k8s资源的调度者： 业务pod根据所写编排的规则进行调度的组件，它会根据使用者编写的规则或者默认规则，根据资源的情况进行调度。
kubelete--k8s接受命令部署节点的大总管： 这个组件也是节点上必备核心之一，接受命令，传输调度，变更信息都需要它来做，如果一个节点的它挂了，整个节点所有业务也会挂掉。
kube-proxy--k8s服务发现者： kubernetes的服务发现是基于服务名，并非传统意义上的域名，想要发现自身的服务，就需要它在中间做架桥，类似网络架桥的组件吧。
core-dns--k8s内部dns组件： 服务名的解析者，与上面的是一对，它负责对内，对外的解析，这个可以理解为超微型的dns服务器。
Pod--k8s对外服务的基础容器组： k8s里经常听到的一个名词。pod是个容器组，可以单个、多个容器组合到一起，对外服务的基本单位。
ingress--k8s对外服务组件: 想要外面的人访问进来，需要这个组件，类似nginx的反代，它会按照编排好的规则进行服务发现以及对外服务。
下面插入几张简单示意图，简单说明下k8s的组件发现机制：
kubernetes的外部服务发现机制：
以下为k8s的外部发现服务的机制，是否通过ingress进入集群内部服务的区分，（图我找了好久，这两张手画的相当详细了），图（1）中标识了在未增加ingress的情况下，直接通过负载或者节点端口然后service发现服务，这种情况有点类似传统的冗余架构，各走各的，每个模块的压力会比较大，节点端口冗余，而且需要多个端口多个域名来区分，在服务模块量比较大的情况下维护起来会特别耗时。图（2）中则是增加了ingress，通过ingress的反代机制，只有一个流量入口，反代到service上，然后进行服务的各种发现，在资源上节约了入口资源，流量不至于太分散，管理起来也比较方便。
（1）
（2）
kubernetes的内部服务发现机制：
以下为内部服务发现机制，对于一个企业来说，并不是需要所有的东西都暴露在公网之上，k8s集群就很好的将一些服务发现内置在了集群内部循环，之前介绍的组件，kube-proxy，core-dns起到至关重要的作用，在这里还要介绍一个概念，（这个概念属于个人理解）service，在k8s内部也好，外部也好，service相当于整个服务pod服务发现的大门，通过service来进行服务的外部，内部发现，同时也具有一定的负载作用，service的作用，连通着外部ingress---->service---->pod、pod---->service---->pod的重要角色，另外要记住，pod是随时可以销毁的，但是因为service的存在，所以，销毁pod之后，再生成一个新的它依旧会被发现的原因，而在内部，这个依旧适用，它会通过kube-proxy和core-dns的组件进行内部服务名的发现，然后进行内部的通信循环。下面的图也很好的说明了这个。
kubernetes的一些简单命令使用：
k8s的命令其实网上很多，一般都会用命名空间和节点label对节点和资源进行控制，所以一些简单的命令还是有必要去记一下：
kubectl get xxxxx -n xxx （在某个明明空间下获取k8s资源信息，这里可以获取节点，业务pod，系统pod等等信息，增加 -o 参数可以指定输出格式）
kubectl logs xxxx -n xxxx （一般用于观察业务pod的日志输出，也可以用于观察节点信息，这个对日常找bug很好用）
kubectl exec -it xxx -n xxxx --/bin/bash （这个命令很像docker，主要是用于进入pod，在日志作用不明显的情况下，进入pod具体排查，在有多个容器组成的pod里面需要指定容器的label）
k8s的编排之类不会在这里说，以上为k8s的简单介绍，欢迎真正的大佬指正，共同学习。
原文地址：https://www.cnblogs.com/adif0028/p/12146397.html