서문 :
이 회사는 초기 사용 K8S의 숫자 해당 그룹의 (는 Kubernetes) 고려 17 년 하반기에 인상이 다른 후, 거의 2 년을 K8S을 인식 이제 처음부터, 그것은, 이용는 Kubernetes의 개척자 중 하나 간주 될 수 있습니다 사용하기 시작 입장에서 학습을 계속 지금 공정하게, 또한 N은 2 년 이상으로,이 회사는 많은 사람들을 가지고 있지만 또한 논문, 하나 개의 비극적 인 역사는 여전히 결국이 일이 무엇인지를 이해하지 않는, 크레이터 계단 미끄러 재생, 이래 추진의 지도력하에, 내가 소개는 Kubernetes, 이전의 설명에 따라 기사를 작성, 기술 문서 거의 건조 제품, 주로 이론적 인 소개 (온라인 많은 정보는, 내가 조금를 수집하는 것으로 간주 될 수 있지만.) 다시 반복, 큰 살인을 소개하는 간단한 방법을 시도하고, 마지막으로 소개 일반적인 명령의 조금있을 것입니다, 온라인 문서 배포 많은, 자세한 설명을 여기하지 않을 무엇을, 어떤 특정 기술 건조 제품, 없다. (그것은 나와 함께 논의 할 용의가 있다면 물론, 다니엘은 매우 결국, 나는 신인 여전히입니다, 환영 여전히 K8S)
무엇는 Kubernetes입니다 :
는 Kubernetes가 사용 약어로 만든 8 자 "ubernete"8 대신에, K8S을 언급했다. 오픈 소스, 여러 호스트에 컨테이너의 응용 프로그램을위한 클라우드 관리 플랫폼인가,는 Kubernetes 목표는 (강력한)는 Kubernetes 응용 프로그램 배포를 제공하는 간단하고 효과적인 계획, 업데이트, 유지 관리의 응용 프로그램 배포 컨테이너를 만드는 것입니다 각 컨테이너 사이에 서로 절연 배포 선박의 방법에 의한 메커니즘 '', 각 컨테이너는 자신의 파일 시스템이 서로 영향을주지 않습니다 컨테이너 사이의 과정은, 우리는 컴퓨팅 리소스를 구별 할 수 있습니다. 는 Kubernetes 먼저 구글 보그 사내 후, 오메가, 그것은 자동화 지원 배포, 대규모 확장 성 응용 프로그램 컨테이너 관리 시스템을 개발하고 전신 인 구글 오픈 소스 컨테이너 오케스트레이션 엔진이다. 프로덕션 환경에서 응용 프로그램을 배포 할 때, 일반적으로 응용 프로그램 요청의 부하를 분산하기 위해 응용 프로그램의 여러 인스턴스를 배포합니다. 는 Kubernetes, 우리는 내부 실행중인 응용 프로그램의 각 인스턴스를 여러 컨테이너를 만든 다음을 통해 내장 된로드 밸런싱 전략이 그룹의 적용 사례를 관리 할 필요가 없습니다 이러한 세부의에 접근하고, 운영 및 유지 보수를 발견 직원이 수동으로 구성하고 복잡한 과정입니다.
위의 요약 아래는 Kubernetes는 생산 수준의 통합을위한 통합 및 용기, 계획, 업데이트, 유지 보수 스케줄링 애플리케이션 아키텍처의 구축을 기반으로합니다. 다양한 지원는 Kubernetes 매우 좋다, 자동 배치, 자동 개폐식 탄성 애플리케이션 컨테이너 관리 지원. 추가는 Kubernetes에서 언어에 대한 친 화성이 거의 모든 언어는 변경 컨테이너 클러스터는 Kubernetes의이는 Kubernetes 더 많은 사람들이 응용 프로그램 수준에 초점을 맞추고있다에서 실행할 수 있습니다보다는 더 아래쪽에 초점을 맞추고,도 매우 좋다.
내부 구성 요소뿐만 아니라 간단한 서비스 검색 메커니즘을는 Kubernetes :
K8S에게 내부 구성 요소를 소개하기 전에, 내가 K8S 노드 개념이 있지만, 우리는, 개념을 포기해야한다 내 친구가이 글을보고 싶어하지만 노드에 대해 생각하지 않는다, 기본 사실은 그 K8S의 클러스터 리소스에 모든 노드 이 메커니즘의 K8S을 이해하는 것은 매우 어려운 경우 지적 전통 경우뿐만 아니라 노드의 운영 및 유지 보수에 확인합니다. 이러한 이해는 내 개인적인 생각이지만, 나는 아직도 기사 도움의 친구를 볼 수 있도록 노력하겠습니다 동안. 지금은 개인이이 제한 배운 때문에, 구성 요소의 K8S을 소개하는 이해의 내 개인적인 방법을 사용하는 경우 잘못된 장소 환영하는 것입니다.
- kubectl 게시자 K8S 명령을 : 우리는 마스터 노드 또는 관리 노드에서 다양한 명령을 필요로 할 때 전체 클러스터 K8S을 관리 kubectl은, 클러스터를 관찰하는이 명령의 발행인, 클러스터 관리, 배포 등입니다 이것은 전체에 명령에 따라 달라집니다.
APIServer - 통신 허브 K8S 클러스터 : API는 이제 K8S 클러스터에 있어야이 개념에 익숙하지 않은, 주문 모두 주어졌다, 심지어는 변경 관리 노드는 정보를 전달하기 위해 그가 걸린 경우에 필요하므로,이 구성 요소의 정보를 전달하는 가. 전체 클러스터가 손실 접촉 할 것이다.
- etcd 누가 데이터 저장 K8S : 큰 가축의 프로젝트 참여가 하나의 K8S 핵심 구성 요소, 규칙을 변경하려면 키 - 값 모드, 전체 클러스터에 대한 정보를 기반으로 클러스터, 데이터 저장으로 수행 할 수 있습니다 혼자, 그들이 그를 저장 여기에.
컨트롤러 관리자 - K8S 자원 관리자, 컨트롤러 : 노드가이 구성 요소에 의해 제어를 통해, 그것은 자원 전체 노드 관찰과 피드백, 심지어 포드 라이프 사이클 수 통제 될 수 있습니다됩니다 자원을 관리 이들의 통제의 고삐.
스케줄러 - K8S 자원 스케줄러 : 비즈니스 자원의 일정에 따라, 규칙 또는 기본 규칙에 따라 사용자가 준비됩니다 안무 스케줄링 구성 요소를 작성 규칙에 따라 수행 포드.
kubelete - K8S 노드에게 위대한 탐험가를 배포하는 명령을 받아 : 이 구성 요소는 핵심 중 하나에 필수 노드, 주문, 전송 스케줄링, 그것은 노드가 연결된 경우, 할 필요가 변경 정보를 가지고, 전체 사업은 모든 노드입니다 그것은이 중단됩니다.
KUBE-프록시 - K8S 서비스 발견이 : 는 Kubernetes 서비스 검색은 서비스 이름을 기반으로, 도메인 이름이 아닌 전통적인 의미에서, 그들은 당신이 네트워크 브리지 그것의 구성 요소와 유사한 다리의 중간에 그것을 할 필요가 자신의 서비스를 찾을 수 있습니다.
- 코어 DNS 내부 DNS 성분 K8S : 리졸버 서비스 명, 및 상기 내부 및 외부 해상도 담당하는 한 쌍의, 이는 초소형 DNS 서버로서 이해 될 수있다.
- 포드는 기본 컨테이너 그룹은 외부 서비스 K8S 자주 K8S에 들었 용어를. 포드 용기의 그룹이고, A는 하나 일 수 그룹화 된 복수의 용기 외부 서비스의 기본 단위.
수신 - 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的简单介绍，欢迎真正的大佬指正，共同学习。