{"id":37030,"date":"2019-10-31T22:15:23","date_gmt":"2019-10-31T19:15:23","guid":{"rendered":"https:\/\/prohoster.info\/blog\/servisnaya-set-ploskost-dannyh-i-ploskosti-upravleniya-service-mesh-data-plane-vs-control-plane\/"},"modified":"2019-10-31T22:15:23","modified_gmt":"2019-10-31T19:15:23","slug":"servisnaya-set-ploskost-dannyh-i-ploskosti-upravleniya-service-mesh-data-plane-vs-control-plane","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/servisnaya-set-ploskost-dannyh-i-ploskosti-upravleniya-service-mesh-data-plane-vs-control-plane","title":{"rendered":"R\u00e9seau de services, \u00ab Plan de donn\u00e9es \u00bb et \u00ab Plan de contr\u00f4le \u00bb (Service mesh data plane vs. control plane)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Bonjour Habr ! Je vous pr\u00e9sente la traduction de l'article \u00abPlan de donn\u00e9es de maillage de services vs plan de contr\u00f4le\u00bb<\/a><\/noindex> l'auteur Matt Klein<\/b>.<\/p>\n

\"R\u00e9seau
\n
\nCette fois, j'ai eu envie de traduire la description des deux composants du maillage de services, le plan de donn\u00e9es et le plan de contr\u00f4le. Cette description m'a sembl\u00e9 la plus claire et la plus int\u00e9ressante, surtout parce qu'elle am\u00e8ne \u00e0 se demander \u00abEst-ce vraiment n\u00e9cessaire ?\u00bb.<\/p>\n

\u00c9tant donn\u00e9 que l'id\u00e9e de la \u00abService mesh\u00bb devient de plus en plus populaire ces deux derni\u00e8res ann\u00e9es (Article original du 10 octobre 2017), et que le nombre d'acteurs dans cet espace a augment\u00e9, j'ai constat\u00e9 une confusion croissante au sein de la communaut\u00e9 technique concernant la mani\u00e8re de comparer et de contraster diff\u00e9rentes solutions.
\n<\/a><\/noindex>
\nLa situation peut \u00eatre mieux d\u00e9crite par les s\u00e9ries de tweets suivants que j'ai \u00e9crites en juillet :<\/p>\n

Confusion sur le maillage de services n\u00b0 1 : Linkerd ~ = Nginx ~ = Haproxy ~ = Envoy. Aucun d'eux n'est \u00e9gal \u00e0 Istio. Istio est quelque chose de tout \u00e0 fait diff\u00e9rent. 1 \/<\/p><\/blockquote>\n

Les premiers sont juste des plans de donn\u00e9es. En eux-m\u00eames, ils ne font rien. Ils doivent \u00eatre configur\u00e9s pour quelque chose de plus. 2 \/<\/p><\/blockquote>\n

Istio est un exemple de plan de contr\u00f4le qui relie les parties ensemble. C'est une couche diff\u00e9rente. \/fin<\/p><\/blockquote>\n

Dans les tweets pr\u00e9c\u00e9dents, plusieurs projets diff\u00e9rents (Linkerd, NGINX, HAProxy, Envoy et Istio) sont mentionn\u00e9s, mais plus important encore, des concepts g\u00e9n\u00e9raux de plan de donn\u00e9es, de maillage de services et de plan de contr\u00f4le sont introduits. Dans ce post, je vais prendre du recul et expliquer ce que j'entends par les termes \u00abplan de donn\u00e9es\u00bb et \u00abplan de contr\u00f4le\u00bb \u00e0 un niveau tr\u00e8s \u00e9lev\u00e9, puis expliquer comment ces termes se rapportent aux projets mentionn\u00e9s dans les tweets.<\/p>\n

Qu'est-ce que le maillage de services (What is a service mesh, really) ?<\/h1>\n

\n\"R\u00e9seau
\nFigure 1 : Aper\u00e7u du maillage de services (Service mesh overview)<\/b><\/p>\n

Figure 1<\/b> illustre le concept de maillage de services au niveau le plus basique. Il y a quatre clusters de services (A-D). Chaque instance de service est li\u00e9e \u00e0 un serveur proxy local. Tout le trafic r\u00e9seau (HTTP, REST, gRPC, Redis, etc.) d'une instance d'application est transmis via le serveur proxy local aux clusters de services externes correspondants. Ainsi, l'instance d'application ne conna\u00eet pas le r\u00e9seau dans son ensemble et ne conna\u00eet que son proxy local. En fait, le r\u00e9seau du syst\u00e8me distribu\u00e9 a \u00e9t\u00e9 retir\u00e9 du service.<\/p>\n

Plan de donn\u00e9es<\/h1>\n

\nDans le maillage de services, le serveur proxy situ\u00e9 localement pour l'application effectue les t\u00e2ches suivantes :<\/p>\n