在这个博客中，阿里巴巴的工程师们谈论了关于Docker、Kubernetes和Istio等服务网格以及其他云原生技术的想法和理解。

这个博客是从英文版翻译而来的。原始版本可以在这里查看。我们使用了部分机器翻译。如果有任何翻译错误，请指出，我们将不胜感激。

关于Docker的想法

在这里，我将介绍读完《Docker实践指南》后的感受。

Docker 是一个专为构建、交付和运行分布式应用程序而设计的 Linux 容器工具集。Docker通过容器化过程来确保应用程序的隔离性和可重用性，并通过虚拟化过程提供功能性方法来保证物理机器的安全性。

在许多方面，Docker是云本地化的拼图，也是其中最早的主要组成之一。

以下的图表展示了Docker可以如何用于提高效率的示例。

Docker是什么？

以下的要点是关于Docker是什么以及它能做什么的总结。

• Dockerは、アプリケーションのライフサイクル全体を連結する一種の契約と表現することができます。その中核的な強みは、アプリケーションの出荷を高速化し、全体的な生産性を向上させることです。

 

• Dockerは仮想マシンとは根本的に異なります。Docker、つまりコンテナ化の概念自体は仮想化ではありません。マシンのハードウェアをシミュレートしているわけでもありません。むしろ、Dockerはアプリケーションを中心に構築されており、オープンなdockerfile標準を使用して、設定や依存関係を含むアプリケーションをカプセル化しています。仮想マシンは、リソース管理に重点を置いてオペレーティングシステム層で動作します。

 

• また、DockerはChefやJenkinsと緊密に統合することができます。

Docker Hubはコンテナイメージ管理の中心であり、Dockerアプリケーションの特徴を最もよく反映しています。各イメージは名前とタグ付けが可能で、固有のIDを持っています。

另外，Docker与应用程序的全部生命周期阶段成功地进行了整合。

• 開発：Dockerは、プロセスがその環境であることを考えると、開発環境の一貫性を確保し、Make、Chef、Puppetなどの従来の設定ツールと連携することができます。また、イメージが小さく、開発者に優しいのも特徴です。Dockerfilesを使用することで、ソースからイメージへの自動化を可能にします。

 

• DevOps：DockerはGitからDocker Hub、Jenkinsまでの自動化されたワークフローを可能にします。継続的なチェックイン、継続的なインテグレーション、継続的なデプロイ、継続的なデリバリーの包括的なワークフローを採用しています。

 

本番環境：Dockerは、SwarmやKubernetesなどのPaaS（Platform-as-a-Service）製品が輝く場所でもあります。

Docker负责以下这些事情。

1、多主机容器的运行状态和配置管理。
2、在多主机和多容器编配环境中管理安全性、日志和故障排除。

关于Kubernetes

正如之前所暗示的，Kubernetes是在容器化应用和Docker流行、开始被用作管理容器的平台之后出现的。在这里，我将分享阅读Kubernetes实践指南后的反思。

为什么选择Kubernetes？

Kubernetes的受欢迎程度与Docker密切相关。由于Docker的广泛应用，Platform-as-a-Service（PaaS）得以实现。Kubernetes是在Google积累了大量大规模数据中心管理经验之后的伟大成果。同时，Kubernetes也受益于当时容器化应用的爆炸式普及。Google的目标是确立新的行业标准，毫无疑问，他们成功实现了这一目标。

Kubernetes承担了真正的云原生革命的重要角色。

谷歌在2004年开始使用容器，并在2006年发布了一个称为控制组（通常称为cgroups）的工具。同时，他们还在云端和IT基础设施中内部使用诸如Borg和Omega等集群管理平台。Kubernetes受到Borg的启发，利用了包括Omega在内的容器管理者的经验和教训。

你可以在这个博客里详细阅读关于这个有魅力的历史的内容。

在未来考虑的事情是，Kubernetes是如何击败了像Compose、Docker Swarm以及Mesos等其他早期的竞争者的呢？简单来说，答案就在于Kubernetes出色的抽象化模型。Kubernetes在设计的核心部分与众不同。要理解Kubernetes，就需要概览与其架构相关的所有概念和术语。

主要的Kubernetes概念

以下是介绍Kubernetes特有概念的内容。通过理解Kubernetes背后的概念，可以更全面地了解Kubernetes的工作原理。

Pod: Podは、Kubertnetesアプリケーションの基本的な実行ユニットです。Podはいくつかのコンテナを組み合わせたもので、すべてが同じホスト上で実行され、同じネットワークネームスペース、IPアドレス、ポートを使用しています。これらのコンテナは、ローカルホストを使用して、お互いに通信したり、発見したりします。さらに、これらのコンテナは同じストレージボリュームを共有することができます。コンテナではなくPodは、Kubernetesの中で最も小さなユニットで、作成、スケジュール、管理を行います。Podは、より高い抽象度と、より柔軟なデプロイと管理モデルを提供します。
コントローラー（Controller）：Controllerはタスク実行のためのロジックユニットで、負荷のスケジューリングや実行はController Managerで管理されます。ReplicationController（RC）はコントローラの特定の実装の1つで、弾力的なスケーリングとローリングアップグレードを担当します。各オブジェクトモデルには、ノード、サービス、エンドポイント、SA、PV、デプロイメント、ジョブなどの対応するコントローラがあります。また、拡張機能を使ってコントローラを実装することもできます。
サービス：Kubernetesにおけるサービスとは、実際のアプリケーションサービスを抽象化したものです。Podにアクセスするための論理セットとポリシーを定義します。サービスはPodの単一アクセスポイント（またはプロキシ）として機能し、バックエンドのPodがどのように動作するかを知らなくてもアプリケーションにアクセスできるようにします。これにより、サービスのプロキシとディスカバリのメカニズムが簡素化され、拡張とメンテナンスが非常に簡単になります。サービスはPod以外にも、Kubernetesクラスタの外部サービスなど、任意のバックエンドのプロキシとして機能することができます。この場合、セレクタは必要ありませんが、サービスと同じ名前のエンドポイントを手動で定義する必要があります。
ラベル（Label）：ラベルは、Podなどのオブジェクトに付けられるキー/値のペアです。ラベルは、Podをサービスやレプリケーションコントローラと緩く結合するために使用されます。
ノード：Kubernetes用語でのノードとは、単にホストやマシンのことです。Kubernetesでは、ノードはワーカーマシンとして定義されており、仮想マシンであっても物理マシンであっても構いません。
もっと詳しく知りたい場合は、ソース自体から入手したり、公式ドキュメントを直接読んだりすることができますが、それはここで見つけることができます。

Kubernetes和主流的CI/CD模型

持续集成和部署是Platform-as-a-Service（PaaS）模型的最显著特点，也是云原生的特征，大多数云服务提供商都提供基于Kubernetes的PaaS模型。因此，通常的用户体验和使用这些模型的具体CI/CD（持续集成和持续交付）流水线将区分不同的服务。通常，CI/CD流水线从项目创建时开始，并渗透到应用程序的每个生命周期阶段。这是CI/CD流水线的核心优势。CI/CD流水线可以集成到开发工作流的所有步骤中，并提供一体化的应用服务体验。

下面，我将介绍几种在Kubernetes上流行的CI/CD工具。

Jenkins：Jenkinsはハドソンから出てきたもので、Javaで実装されています。おそらく現在最も広く使われているCI/CDツールです。

TeamCity：TeamCityは、公開されている課題追跡やフォーラム、100種類のビルド構成など、強力な機能がたくさんあります。

CircleCI: CircleCiは、安全な方法で大規模な開発プロセスを簡単に自動化したい場合に最適です。そのクライアントはFacebook、Kickstarter、Spotifyなどです。

Travis CI： Travis CIは自信を持ってテストやデプロイを行うのに役立ちます。実際、Apacheのプロジェクトでは、統合テストにTravis CIを使用しています。各PRにはTCタスクがあり、ユニットテストを実行し、コードが仕様通りであることを確認します。

Drone CI： Droneは、忙しい開発チームに便利なセルフサービスの継続的デリバリープラットフォームです。彼らのクライアントには、Cisco、Ebay、Gannett、VMWare、Capital Oneなどがあります。

与Kubernetes进行协作的API对象和元数据。

嗯，Kubernetes中最重要的是与Kubernetes集成的API对象和元数据。

kuberctl：KuberctlはKubernetesのコマンドラインツールです。

KubernetesのAPIに直接アクセス:Kubernetes API ServerはKubernetesのアクセスポイントです。RESTfulな操作をサービスし、Swaggerを統合してAPIを定義・記述します。詳しくはこちらをご覧ください。
Kubebuilder SDK:KubebuilderはKubernetesのメインSDKです。
実際には、メタデータはAPIオブジェクトの基本情報を定義するだけです。それはメタデータフィールドで表現され、以下の属性を持っています。
namespace： namespacフィールドは、API オブジェクトの名前空間を指定します。namespaceフィールドは、APIオブジェクトの名前空間を指定します。名前空間は、Kubernetesがサポートする同じ物理クラスタにバックアップされた複数の仮想クラスタとして定義することができます。異なるプロジェクト、チーム、ユーザーは異なる名前空間を使用して、他のポリシー以外にも管理やカスタマイズされたアクセス制御を行うことができます。ノード以外のAPIオブジェクトはすべて名前空間に属します。これはmetadata.namespaceによって定義されます。このフィールドが定義されていない場合は、defaultと呼ばれるデフォルトの名前空間が使用されます。
name: nameフィールドはAPIオブジェクトの名前を指定します。nameフィールドは重要な属性です。これは、metadata.nameAll API オブジェクトは、Node を除くすべての API オブジェクトが名前空間に属しています。同じ名前空間内では、これらのオブジェクトは名前で識別されます。したがって、APIオブジェクトの名前は、ネームスペース内で一意でなければなりません。ノードとネームスペースはシステム内で一意でなければなりません。
ラベル：ラベルフィールドは、APIオブジェクトのラベルを指定します。ラベルは、APIオブジェクトに添付されるキー/値のペアです。ラベルは、オブジェクトの識別属性を指定するために使用することを意図しており、ユーザーにとって意味があり、関連性がありますが、コアシステムに直接セマンティクスを意味するものではありません。ラベルは、オブジェクトのサブセットを整理したり、選択したりするために使用することができます。ReplicationController と ReplicationService は、Podに関連付けるためにラベルを使用します。Podはラベルを使ってノードを選択することもできます。
アノテーション:アノテーションフィールドは、API オブジェクトのアノテーションを指定します。アノテーションフィールドは、オブジェクトに任意の非識別メタデータを添付するために使用されますが、オブジェクトの選択には使用できません。アノテーションは、構造化または非構造化の長いデータであることができ、キー/値のペアでもあります。

关于服务网格

在这里，我想立即来看一下Service Mesh，它真的是除了Kubernetes和Docker之外非常重要的存在。对我来说，Service Mesh的核心优势是它的控制功能，特别是Service Mesh中的Istio在某些方面特别出色。

如果Istio的模型被标准化并扩大推广，实际上可以成为容器化应用的事实PaaS产品。然而，我认为Apache的Dubbo、Envoy、NGINX以及Conduit的服务网格也是有效的整合选择。

我认为Istio是一个非常优秀的选择，让我们首先把重点放在它上面。

Istio是什么？

了解服务网格的原理，就需要理解服务网格的设计原则。让我们来看看Istio的设计原则是什么。简单来说，在实施容器调度平台之前，服务的抽象化模型应该先到位。请考虑下面的图示。

如果你想详细了解Istio是什么，请查看这里的官方说明。

通常来说，Istio的服务模型包括服务和其实例的抽象模型。Istio独立于基础平台，并拥有特定平台的适配器，它可以从平台中发现的元数据输入到模型对象的各个字段。在其中，服务是一个应用程序单元，具有其他服务引用的唯一名称，而服务实例是实现服务的Pod、虚拟机或容器。一个服务可能存在多个版本。

下一个是服务模型。每个服务都有一个完全修饰域名（或FQDN）和一个或多个监听连接的端口。服务可以具有与其关联的单个负载均衡器和虚拟IP地址。此外，服务模型还包括实例。每个服务可以拥有一个或多个实例，并作为服务的实际显现。实例表示类似于Pod的实体，并且每个实例都具有网络的端点。

Istio的设计中包含了服务的版本，每个版本通过与特定版本相关联的唯一标签集来区分。另一个概念是标签，它是分配给特定服务版本实例的简单键值对。同一版本的所有实例必须具有相同的标签。Istio期望基础平台提供服务注册表和服务发现机制。

进一步介绍应该了解的有关云原生的知识。

在以上提到的Docker、Kubernetes和Istio等服务网格的讨论中，我遗漏了一个重要的事情，那就是”云原生”。那么，什么是”云原生”呢？它意味着什么？要成为”云原生”，有什么要求？虽然有很多种解释，但根据Cloud Native Computing Foundation（CNCF）的说法，可以理解为以下几点：

云原生技术和解决方案指的是在云上构建和运行可扩展应用程序的技术。云原生是随着容器技术的发展而出现的，比如Docker和Kubernetes。它通常具有无状态、可持续交付和支持微服务等特点。

云原生技术和解决方案保证了出色的容错性和易于管理性，尤其是与自动化的CI/CD流水线相结合，可以以较小的工作量带来强大的影响力。

根据CNCF的数据，现在有关于云原生和”云原生”概念的定义，其中包括了Kubernetes的使用，但是Kubernetes并不是拼图中唯一的一块，它只是一个开始而已。在目前的CNCF景观中，传统的微服务解决方案Dubbo也成为了一部分，使得越来越多的人被这些解决方案提供的独特功能所吸引，从而被云原生所吸引。

换言之，从今天的云原生景观来看，在很多方面，云原生可能从Kubernetes开始，最终采用像Istio这样的服务网格解决方案。正如我们在这篇博客中看到的那样，一开始有Docker，然后是Kubernetes，现在又有了服务网格。

阿里巴巴云拥有两个数据中心，并拥有全球超过60个可用区，是亚太地区的领先云基础设施服务提供商（2019年Gartner报告）。
更多阿里巴巴云的详细信息，请访问我们的官方网页。