mirror of https://github.com/istio/istio.io.git
Change scope of doc testing to /docs (#7593)
This commit is contained in:
parent
8e4673c709
commit
eff0d43a27
|
@ -5,5 +5,4 @@ description: Get a bit more in-depth info about the Istio project.
|
|||
sidebar_singlecard: true
|
||||
weight: 15
|
||||
icon: about
|
||||
test: n/a
|
||||
---
|
||||
|
|
|
@ -7,7 +7,6 @@ aliases:
|
|||
- /bugs/index.html
|
||||
- /help/bugs/
|
||||
icon: bugs
|
||||
test: no
|
||||
---
|
||||
|
||||
Oh no! You found a bug? We'd love to hear about it.
|
||||
|
|
|
@ -6,5 +6,4 @@ weight: 5
|
|||
aliases:
|
||||
- /community
|
||||
icon: community
|
||||
test: n/a
|
||||
---
|
||||
|
|
|
@ -5,7 +5,6 @@ weight: 30
|
|||
icon: customers
|
||||
keywords: [community]
|
||||
skip_seealso: true
|
||||
test: n/a
|
||||
---
|
||||
|
||||
Tons of people are using Istio. Maybe you should too?
|
||||
|
|
|
@ -4,7 +4,6 @@ description: Information on the various ways to participate and interact with th
|
|||
weight: 10
|
||||
keywords: [community]
|
||||
icon: community
|
||||
test: n/a
|
||||
---
|
||||
Istio is an open source project with an active community that supports its use and on-going development. We'd love for you
|
||||
to join us and get involved!
|
||||
|
|
|
@ -5,7 +5,6 @@ weight: 20
|
|||
icon: partners
|
||||
keywords: [community]
|
||||
skip_seealso: true
|
||||
test: n/a
|
||||
---
|
||||
|
||||
Istio benefits from an ecosystem of great partners. Check 'em out and learn how they make Istio even better.
|
||||
|
|
|
@ -12,7 +12,6 @@ aliases:
|
|||
keywords: [contribute, github, docs, shortcodes, code-blocks, website]
|
||||
list_below: true
|
||||
icon: contribute
|
||||
test: n/a
|
||||
---
|
||||
|
||||
Welcome to the Istio documentation contribution guides. This section contains
|
||||
|
|
|
@ -8,7 +8,6 @@ aliases:
|
|||
- /about/contribute/writing-a-new-topic.html
|
||||
- /create
|
||||
keywords: [contribute]
|
||||
test: n/a
|
||||
---
|
||||
|
||||
To contribute new documentation to Istio, just follow these steps:
|
||||
|
|
|
@ -3,7 +3,6 @@ title: Build and serve the website locally
|
|||
description: Explains how to locally build, test, serve, and preview the website.
|
||||
weight: 5
|
||||
keywords: [contribute, serve, Docker, Hugo, build]
|
||||
test: no
|
||||
---
|
||||
|
||||
After making your contribution to our website, ensure the changes
|
||||
|
|
|
@ -3,7 +3,6 @@ title: Add Code Blocks
|
|||
description: Explains how to include code in your documentation.
|
||||
weight: 8
|
||||
keywords: [contribute, documentation, guide, code-block]
|
||||
test: no
|
||||
---
|
||||
|
||||
Code blocks in the Istio documentation are embedded preformatted block of
|
||||
|
|
|
@ -3,7 +3,6 @@ title: Diagram Creation Guidelines
|
|||
description: Provides assets and instructions to create diagrams for the Istio documentation.
|
||||
weight: 13
|
||||
keywords: [contribute,diagram,documentation,guide]
|
||||
test: n/a
|
||||
---
|
||||
|
||||
Welcome to the Istio diagram guide!
|
||||
|
|
|
@ -4,7 +4,6 @@ description: Explains the standard markup used to format Istio documentation.
|
|||
weight: 10
|
||||
aliases:
|
||||
keywords: [contribute]
|
||||
test: no
|
||||
---
|
||||
|
||||
This page shows the formatting standards for the Istio documentation. Istio uses
|
||||
|
|
|
@ -3,7 +3,6 @@ title: Front matter
|
|||
description: Explains the front matter used in our documentation and the fields available.
|
||||
weight: 6
|
||||
keywords: [metadata,navigation,table-of-contents]
|
||||
test: no
|
||||
---
|
||||
|
||||
The front matter is YAML code in between triple-dashed lines at the top of each
|
||||
|
|
|
@ -10,7 +10,6 @@ aliases:
|
|||
- /about/contribute/editing
|
||||
- /about/contribute/staging-your-changes
|
||||
keywords: [contribute,community,github,pr]
|
||||
test: n/a
|
||||
---
|
||||
|
||||
The Istio documentation follows the standard [GitHub collaboration flow](https://guides.github.com/introduction/flow/)
|
||||
|
|
|
@ -3,7 +3,6 @@ title: Remove Retired Documentation
|
|||
description: Details how to contribute retired documentation to Istio.
|
||||
weight: 4
|
||||
keywords: [contribute]
|
||||
test: n/a
|
||||
---
|
||||
|
||||
To remove documentation from Istio, please follow these simple steps:
|
||||
|
|
|
@ -3,7 +3,6 @@ title: Documentation Review Process
|
|||
description: Shows you how changes to the Istio documentation and website are reviewed and approved.
|
||||
weight: 7
|
||||
keywords: [contribute,community,github,pr,documentation,review, approval]
|
||||
test: n/a
|
||||
---
|
||||
|
||||
The maintainers and working group leads of the Istio Docs Working Group (WG) approve
|
||||
|
|
|
@ -8,7 +8,6 @@ aliases:
|
|||
- /about/contribute/writing-a-new-topic.html
|
||||
- /create
|
||||
keywords: [contribute]
|
||||
test: no
|
||||
---
|
||||
|
||||
Hugo shortcodes are special placeholders with a certain syntax that you can add
|
||||
|
|
|
@ -6,7 +6,6 @@ aliases:
|
|||
- /docs/welcome/contribute/style-guide.html
|
||||
- /docs/reference/contribute/style-guide.html
|
||||
keywords: [contribute]
|
||||
test: n/a
|
||||
---
|
||||
|
||||
All content accepted into the Istio documentation must be **clear** and
|
||||
|
|
|
@ -6,7 +6,6 @@ aliases:
|
|||
- /docs/welcome/contribute/style-guide.html
|
||||
- /docs/reference/contribute/style-guide.html
|
||||
keywords: [contribute, documentation, guide, code-block]
|
||||
test: n/a
|
||||
---
|
||||
|
||||
To provide clarity to our users, use the standard terms in this section
|
||||
|
|
|
@ -8,7 +8,6 @@ aliases:
|
|||
- /docs/welcome/feature-stages.html
|
||||
- /docs/home/roadmap.html
|
||||
icon: feature-status
|
||||
test: n/a
|
||||
---
|
||||
|
||||
<!--
|
||||
|
|
|
@ -5,7 +5,6 @@ weight: 110
|
|||
icon: log
|
||||
skip_seealso: true
|
||||
skip_byline: true
|
||||
test: n/a
|
||||
---
|
||||
|
||||
This page shows you the most recent changes to this website's content.
|
||||
|
|
|
@ -3,7 +3,6 @@ title: Media Resources
|
|||
description: Official Istio resources for digital and printed materials.
|
||||
weight: 90
|
||||
icon: istio-blue-logo
|
||||
test: n/a
|
||||
---
|
||||
|
||||
Here are a few assets in case you want to show off your support for Istio, integration to Istio, or want to link back to
|
||||
|
|
|
@ -3,7 +3,6 @@ title: Build & Release Cadence
|
|||
description: How we manage, number, and support Istio releases.
|
||||
weight: 15
|
||||
icon: cadence
|
||||
test: no
|
||||
---
|
||||
|
||||
We produce new builds of Istio for each commit. Around once a quarter or so, we build a Long Term Support (LTS) release,
|
||||
|
|
|
@ -3,7 +3,6 @@ title: Security Vulnerabilities
|
|||
description: How we handle security vulnerabilities.
|
||||
weight: 35
|
||||
icon: vulnerabilities
|
||||
test: n/a
|
||||
---
|
||||
|
||||
We are very grateful to the security researchers and users that report
|
||||
|
|
|
@ -8,7 +8,6 @@ aliases:
|
|||
- /blog/0.1-auth.html
|
||||
- /blog/istio-auth-for-microservices.html
|
||||
target_release: 0.1
|
||||
test: n/a
|
||||
---
|
||||
|
||||
Conventional network security approaches fail to address security threats to distributed applications deployed in dynamic production environments. Today, we describe how Istio authentication enables enterprises to transform their security posture from just protecting the edge to consistently securing all inter-service communications deep within their applications. With Istio authentication, developers and operators can protect services with sensitive data against unauthorized insider access and they can achieve this without any changes to the application code!
|
||||
|
|
|
@ -7,7 +7,6 @@ attribution: Frank Budinsky
|
|||
keywords: [traffic-management,canary]
|
||||
aliases:
|
||||
- /blog/canary-deployments-using-istio.html
|
||||
test: no
|
||||
---
|
||||
|
||||
{{< tip >}}
|
||||
|
|
|
@ -7,7 +7,6 @@ attribution: Spike Curtis
|
|||
aliases:
|
||||
- /blog/using-network-policy-in-concert-with-istio.html
|
||||
target_release: 0.1
|
||||
test: no
|
||||
---
|
||||
|
||||
The use of Network Policy to secure applications running on Kubernetes is a now a widely accepted industry best practice. Given that Istio also supports policy, we want to spend some time explaining how Istio policy and Kubernetes Network Policy interact and support each other to deliver your application securely.
|
||||
|
|
|
@ -5,5 +5,4 @@ weight: 20
|
|||
icon: blog
|
||||
decoration: dot
|
||||
list_by_publishdate: true
|
||||
test: n/a
|
||||
---
|
||||
|
|
|
@ -8,7 +8,6 @@ keywords: [adapters,mixer,policies,telemetry]
|
|||
aliases:
|
||||
- /blog/mixer-adapter-model.html
|
||||
target_release: 0.2
|
||||
test: n/a
|
||||
---
|
||||
|
||||
Istio 0.2 introduced a new Mixer adapter model which is intended to increase Mixer’s flexibility to address a varied set of infrastructure backends. This post intends to put the adapter model in context and explain how it works.
|
||||
|
|
|
@ -9,7 +9,6 @@ aliases:
|
|||
- /blog/posts/2017/mixer-spof-myth.html
|
||||
- /blog/mixer-spof-myth.html
|
||||
target_release: 0.3
|
||||
test: n/a
|
||||
---
|
||||
|
||||
As [Mixer](/docs/reference/config/policy-and-telemetry/) is in the request path, it is natural to question how it impacts
|
||||
|
|
|
@ -5,5 +5,4 @@ weight: 10
|
|||
icon: blog
|
||||
decoration: dot
|
||||
list_by_publishdate: true
|
||||
test: n/a
|
||||
---
|
||||
|
|
|
@ -7,7 +7,6 @@ subtitle: Ingress AWS Network Load Balancer
|
|||
attribution: Julien SENON
|
||||
keywords: [ingress,traffic-management,aws]
|
||||
target_release: 1.0
|
||||
test: no
|
||||
---
|
||||
|
||||
{{< tip >}}
|
||||
|
|
|
@ -6,7 +6,6 @@ subtitle:
|
|||
attribution: Dinesh Subhraveti (AppOrbit and Columbia University)
|
||||
keywords: [appswitch,performance]
|
||||
target_release: 1.0
|
||||
test: n/a
|
||||
---
|
||||
|
||||
{{< quote >}}
|
||||
|
|
|
@ -7,7 +7,6 @@ subtitle: Mesh-external service entries for egress HTTPS traffic
|
|||
attribution: Vadim Eisenberg
|
||||
keywords: [traffic-management,egress,https]
|
||||
target_release: 1.1
|
||||
test: no
|
||||
---
|
||||
|
||||
In many cases, not all the parts of a microservices-based application reside in a _service mesh_. Sometimes, the
|
||||
|
|
|
@ -7,7 +7,6 @@ subtitle: Istio Egress Control Options for MongoDB traffic
|
|||
attribution: Vadim Eisenberg
|
||||
keywords: [traffic-management,egress,tcp,mongo]
|
||||
target_release: 1.1
|
||||
test: no
|
||||
---
|
||||
|
||||
In the [Consuming External TCP Services](/blog/2018/egress-tcp/) blog post, I described how external services
|
||||
|
|
|
@ -6,7 +6,6 @@ last_update: 2019-03-04
|
|||
attribution: Vadim Eisenberg and Ronen Schaffer (IBM)
|
||||
keywords: [egress,traffic-management,access-control,monitoring]
|
||||
target_release: 1.1
|
||||
test: no
|
||||
---
|
||||
|
||||
While Istio's main focus is management of traffic between microservices inside a service mesh, Istio can also manage
|
||||
|
|
|
@ -9,7 +9,6 @@ aliases:
|
|||
- /docs/tasks/traffic-management/egress-tcp/
|
||||
keywords: [traffic-management,egress,tcp]
|
||||
target_release: 1.0
|
||||
test: no
|
||||
---
|
||||
|
||||
{{< tip >}}
|
||||
|
|
|
@ -5,7 +5,6 @@ publishdate: 2018-07-09
|
|||
subtitle:
|
||||
attribution: Nupur Garg and Douglas Reid
|
||||
target_release: 0.8
|
||||
test: no
|
||||
---
|
||||
|
||||
This post shows how to direct Istio logs to [Stackdriver](https://cloud.google.com/stackdriver/)
|
||||
|
|
|
@ -5,7 +5,6 @@ subtitle: How HP is building its next-generation footwear personalization platfo
|
|||
publishdate: 2018-07-31
|
||||
attribution: Steven Ceuppens, Chief Software Architect @ HP FitStation, Open Source Advocate & Contributor
|
||||
target_release: 1.0
|
||||
test: n/a
|
||||
---
|
||||
|
||||
The FitStation team at HP strongly believes in the future of Kubernetes, BPF and service-mesh as the next standards in cloud infrastructure. We are also very happy to see Istio coming to its official Istio 1.0 release -- thanks to the joint collaboration that started at Google, IBM and Lyft beginning in May 2017.
|
||||
|
|
|
@ -7,7 +7,6 @@ attribution: Sandeep Parikh
|
|||
twitter: crcsmnky
|
||||
keywords: [traffic-management,gateway]
|
||||
target_release: 1.0
|
||||
test: no
|
||||
---
|
||||
|
||||
Traffic management is one of the critical benefits provided by Istio. At the heart of Istio’s traffic management is the ability to decouple traffic flow and infrastructure scaling. This lets you control your traffic in ways that aren’t possible without a service mesh like Istio.
|
||||
|
|
|
@ -6,7 +6,6 @@ subtitle:
|
|||
attribution: Limin Wang
|
||||
keywords: [authorization,rbac,security]
|
||||
target_release: 0.8
|
||||
test: no
|
||||
---
|
||||
|
||||
Micro-segmentation is a security technique that creates secure zones in cloud deployments and allows organizations to
|
||||
|
|
|
@ -5,7 +5,6 @@ description: Istio hosting an all day Twitch stream to celebrate the 1.0 release
|
|||
publishdate: 2018-08-03
|
||||
attribution: Spencer Krum, IBM
|
||||
target_release: 1.0
|
||||
test: n/a
|
||||
---
|
||||
|
||||
To celebrate the 1.0 release and to promote the software to a wider audience, the Istio community is hosting an all day live stream on Twitch on August 17th.
|
||||
|
|
|
@ -6,7 +6,6 @@ subtitle: Using multiple Istio control planes and RBAC to create multi-tenancy
|
|||
attribution: John Joyce and Rich Curran
|
||||
keywords: [tenancy]
|
||||
target_release: 0.7
|
||||
test: no
|
||||
---
|
||||
|
||||
Multi-tenancy is commonly used in many environments across many different applications,
|
||||
|
|
|
@ -6,7 +6,6 @@ subtitle: Routing rules for HTTP traffic
|
|||
attribution: Christian Posta
|
||||
keywords: [traffic-management,mirroring]
|
||||
target_release: 0.5
|
||||
test: no
|
||||
---
|
||||
|
||||
Trying to enumerate all the possible combinations of test cases for testing services in non-production/test environments can be daunting. In some cases, you'll find that all of the effort that goes into cataloging these use cases doesn't match up to real production use cases. Ideally, we could use live production use cases and traffic to help illuminate all of the feature areas of the service under test that we might miss in more contrived testing environments.
|
||||
|
|
|
@ -6,7 +6,6 @@ subtitle:
|
|||
attribution: Frank Budinsky (IBM) and Shriram Rajagopalan (VMware)
|
||||
keywords: [traffic-management]
|
||||
target_release: 0.7
|
||||
test: no
|
||||
---
|
||||
|
||||
Up until now, Istio has provided a simple API for traffic management using four configuration resources:
|
||||
|
|
|
@ -5,5 +5,4 @@ weight: 9
|
|||
icon: blog
|
||||
decoration: dot
|
||||
list_by_publishdate: true
|
||||
test: n/a
|
||||
---
|
||||
|
|
|
@ -5,7 +5,6 @@ description: Istio has a new discussion board.
|
|||
publishdate: 2019-01-10
|
||||
aliases:
|
||||
- /news/2019/announcing-discuss.istio.io
|
||||
test: n/a
|
||||
---
|
||||
|
||||
We in the Istio community have been working to find the right medium for users to engage with other members of the community -- to ask questions,
|
||||
|
|
|
@ -5,7 +5,6 @@ publishdate: 2019-11-14
|
|||
attribution: Neeraj Poddar (Aspen Mesh)
|
||||
keywords: [client-go,tools,crd]
|
||||
target_release: 1.4
|
||||
test: no
|
||||
---
|
||||
|
||||
We are pleased to announce the initial release of the Istio
|
||||
|
|
|
@ -6,7 +6,6 @@ publishdate: 2019-09-18
|
|||
attribution: Anton Aleksandrov (IBM)
|
||||
keywords: [security,oidc,jwt,policies]
|
||||
target_release: 1.3
|
||||
test: no
|
||||
---
|
||||
|
||||
If you are running your containerized applications on Kubernetes, you can benefit from using the App Identity and Access Adapter for an abstracted level of security with zero code changes or redeploys.
|
||||
|
|
|
@ -6,7 +6,6 @@ subtitle:
|
|||
attribution: Dinesh Subhraveti (AppOrbit and Columbia University)
|
||||
keywords: [appswitch,performance]
|
||||
target_release: 1.0
|
||||
test: n/a
|
||||
---
|
||||
|
||||
We are going through an interesting cycle of application decomposition and recomposition. While the microservice paradigm is driving monolithic applications to be broken into separate individual services, the service mesh approach is helping them to be connected back together into well-structured applications. As such, microservices are logically separate but not independent. They are usually closely interdependent and taking them apart introduces many new concerns such as need for mutual authentication between services. Istio directly addresses most of those issues.
|
||||
|
|
|
@ -6,7 +6,6 @@ publishdate: 2019-01-10
|
|||
keywords: [ingress,traffic-management]
|
||||
attribution: Julien Senon
|
||||
target_release: 1.0
|
||||
test: no
|
||||
---
|
||||
|
||||
This post provides instructions to manually create a custom ingress [gateway](/docs/reference/config/networking/gateway/) with automatic provisioning of certificates based on cert-manager.
|
||||
|
|
|
@ -7,7 +7,6 @@ attribution: Manish Chugtu
|
|||
twitter: chugtum
|
||||
keywords: [kubernetes,sidecar-injection, traffic-management]
|
||||
target_release: 1.0
|
||||
test: no
|
||||
---
|
||||
A simple overview of an Istio service-mesh architecture always starts with describing the control-plane and data-plane.
|
||||
|
||||
|
|
|
@ -5,7 +5,6 @@ publishdate: 2019-11-14
|
|||
attribution: Lei Tang (Google)
|
||||
keywords: [security, kubernetes, certificates, DNS]
|
||||
target_release: 1.4
|
||||
test: n/a
|
||||
---
|
||||
|
||||
By default, Citadel manages the DNS certificates of the Istio control plane.
|
||||
|
|
|
@ -6,7 +6,6 @@ subtitle: An Istio Egress Gateway performance assessment
|
|||
attribution: Jose Nativio, IBM
|
||||
keywords: [performance,traffic-management,egress,mongo]
|
||||
target_release: 1.0
|
||||
test: n/a
|
||||
---
|
||||
|
||||
The main objective of this investigation was to determine the impact on performance and resource utilization when an egress gateway is added in the service mesh to access an external service (MongoDB, in this case). The steps to configure an egress gateway for an external MongoDB are described in the blog [Consuming External MongoDB Services](/blog/2018/egress-mongo/).
|
||||
|
|
|
@ -5,7 +5,6 @@ description: Attacks involving egress traffic and requirements for egress traffi
|
|||
publishdate: 2019-05-22
|
||||
attribution: Vadim Eisenberg (IBM)
|
||||
keywords: [traffic-management,egress,security]
|
||||
test: n/a
|
||||
---
|
||||
|
||||
This is part 1 in a new series about secure control of egress traffic in Istio that I am going to publish.
|
||||
|
|
|
@ -6,7 +6,6 @@ publishdate: 2019-07-10
|
|||
attribution: Vadim Eisenberg (IBM)
|
||||
keywords: [traffic-management,egress,security,gateway,tls]
|
||||
target_release: 1.2
|
||||
test: n/a
|
||||
---
|
||||
|
||||
Welcome to part 2 in our new series about secure control of egress traffic in Istio.
|
||||
|
|
|
@ -6,7 +6,6 @@ publishdate: 2019-07-22
|
|||
attribution: Vadim Eisenberg (IBM)
|
||||
keywords: [traffic-management,egress,security,gateway,tls]
|
||||
target_release: 1.2
|
||||
test: n/a
|
||||
---
|
||||
|
||||
Welcome to part 3 in our series about secure control of egress traffic in Istio.
|
||||
|
|
|
@ -5,7 +5,6 @@ publishdate: 2019-08-05
|
|||
attribution: Louis Ryan (Google), Sandeep Parikh (Google)
|
||||
keywords: [apis,composability,evolution]
|
||||
target_release: 1.2
|
||||
test: n/a
|
||||
---
|
||||
|
||||
One of Istio’s main goals has always been, and continues to be, enabling teams to develop abstractions that work best for their specific organization and workloads. Istio provides robust and powerful building blocks for service-to-service networking. Since [Istio 0.1](/news/releases/0.x/announcing-0.1), the Istio team has been learning from production users about how they map their own architectures, workloads, and constraints to Istio’s capabilities, and we’ve been evolving Istio’s APIs to make them work better for you.
|
||||
|
|
|
@ -6,7 +6,6 @@ subtitle:
|
|||
attribution: Martin Ostrowski (Google), Frank Budinsky (IBM)
|
||||
keywords: [install,configuration,istioctl,operator]
|
||||
target_release: 1.4
|
||||
test: no
|
||||
---
|
||||
|
||||
Kubernetes [operators](https://kubernetes.io/docs/concepts/extend-kubernetes/operator/) provide
|
||||
|
|
|
@ -6,7 +6,6 @@ subtitle:
|
|||
attribution: David Ebbo (Google)
|
||||
keywords: [debugging,istioctl,configuration]
|
||||
target_release: 1.4
|
||||
test: n/a
|
||||
---
|
||||
|
||||
Istio 1.4 introduces an experimental new tool to help you analyze and debug your clusters running Istio.
|
||||
|
@ -48,4 +47,4 @@ each release.
|
|||
|
||||
In fact, we would welcome suggestions from Istio users. Specifically, if you encounter a situation
|
||||
where you think an issue could be detected via configuration analysis, but is not currently flagged
|
||||
by `analyze`, please do let us know. The best way to do this is to [open an issue on GitHub](https://github.com/istio/istio/issues).
|
||||
by `analyze`, please do let us know. The best way to do this is to [open an issue on GitHub](https://github.com/istio/istio/issues).
|
||||
|
|
|
@ -6,7 +6,6 @@ publishdate: 2019-10-02
|
|||
attribution: Vadim Eisenberg (IBM)
|
||||
keywords: [traffic-management,multicluster,security,gateway,tls]
|
||||
target_release: 1.3
|
||||
test: n/a
|
||||
---
|
||||
|
||||
Various compliance standards require protection of sensitive data environments. Some of the important standards and the
|
||||
|
|
|
@ -6,7 +6,6 @@ subtitle: An overview of Istio 1.1 performance improvements
|
|||
attribution: Surya V Duggirala (IBM), Mandar Jog (Google), Jose Nativio (IBM)
|
||||
keywords: [performance,scalability,scale,benchmarks]
|
||||
target_release: 1.1
|
||||
test: n/a
|
||||
---
|
||||
|
||||
Hyper-scale, microservice-based cloud environments have been exciting to build but challenging to manage. Along came Kubernetes (container orchestration) in 2014, followed by Istio (container service management) in 2017. Both open-source projects enable developers to scale container-based applications without spending too much time on administration tasks.
|
||||
|
|
|
@ -6,7 +6,6 @@ publishdate: 2019-09-18
|
|||
attribution: Idan Zach (IBM)
|
||||
keywords: [mixer,adapter,knative,scale-from-zero]
|
||||
target_release: 1.3
|
||||
test: n/a
|
||||
---
|
||||
|
||||
This post demonstrates how you can use [Mixer](/faq/mixer/) to push application logic
|
||||
|
|
|
@ -5,7 +5,6 @@ publishdate: 2019-09-28
|
|||
attribution: Neeraj Poddar (Aspen Mesh)
|
||||
keywords: [monitoring,blackhole,passthrough]
|
||||
target_release: 1.3
|
||||
test: no
|
||||
---
|
||||
|
||||
Understanding, controlling and securing your external service access is one
|
||||
|
|
|
@ -6,7 +6,6 @@ subtitle:
|
|||
attribution: Frank Budinsky (IBM)
|
||||
keywords: [traffic-management,multicluster]
|
||||
target_release: 1.0
|
||||
test: no
|
||||
---
|
||||
|
||||
If you've spent any time looking at Istio, you've probably noticed that it includes a lot of features that
|
||||
|
|
|
@ -6,7 +6,6 @@ last_update: 2019-09-05
|
|||
subtitle:
|
||||
attribution: Megan O'Keefe (Google), John Howard (Google), Mandar Jog (Google)
|
||||
keywords: [performance,scalability,scale,benchmarks]
|
||||
test: n/a
|
||||
---
|
||||
|
||||
Service meshes add a lot of functionality to application deployments, including [traffic policies](/docs/concepts/what-is-istio/#traffic-management), [observability](/docs/concepts/what-is-istio/#observability), and [secure communication](/docs/concepts/what-is-istio/#security). But adding a service mesh to your environment comes at a cost, whether that's time (added latency) or resources (CPU cycles). To make an informed decision on whether a service mesh is right for your use case, it's important to evaluate how your application performs when deployed with a service mesh.
|
||||
|
|
|
@ -5,7 +5,6 @@ description: Configure Istio ingress gateway to act as a proxy for external serv
|
|||
publishdate: 2019-10-15
|
||||
attribution: Vadim Eisenberg (IBM)
|
||||
keywords: [traffic-management,ingress,https,http]
|
||||
test: no
|
||||
---
|
||||
|
||||
The [Control Ingress Traffic](/docs/tasks/traffic-management/ingress/ingress-control/) and the
|
||||
|
|
|
@ -5,7 +5,6 @@ publishdate: 2019-06-07
|
|||
attribution: Oliver Liu
|
||||
keywords: [security, PKI, certificate, Citadel]
|
||||
target_release: 1.1
|
||||
test: n/a
|
||||
---
|
||||
|
||||
Istio self-signed certificates have historically had a 1 year default lifetime.
|
||||
|
|
|
@ -6,7 +6,6 @@ last_update: 2019-09-27
|
|||
attribution: Rigs Caballero, Google
|
||||
keywords: [community,blog,contribution,guide,guideline,event]
|
||||
target_release: 1.3
|
||||
test: n/a
|
||||
---
|
||||
|
||||
Welcome to the Istio blog!
|
||||
|
|
|
@ -5,7 +5,6 @@ publishdate: 2019-09-10
|
|||
attribution: Phillip Quy Le (Google)
|
||||
keywords: [security, PKI, certificate, nodeagent, sds]
|
||||
target_release: 1.2
|
||||
test: n/a
|
||||
---
|
||||
|
||||
In Istio 1.3, we are taking advantage of improvements in Kubernetes to issue certificates for workload instances more securely.
|
||||
|
|
|
@ -6,7 +6,6 @@ subtitle:
|
|||
attribution: Yangmin Zhu (Google)
|
||||
keywords: [security, RBAC, access control, authorization]
|
||||
target_release: 1.4
|
||||
test: no
|
||||
---
|
||||
|
||||
Istio 1.4 introduces the
|
||||
|
|
|
@ -5,7 +5,6 @@ publishdate: 2019-11-14
|
|||
attribution: Lei Tang (Google)
|
||||
keywords: [security, kubernetes, webhook]
|
||||
target_release: 1.4
|
||||
test: n/a
|
||||
---
|
||||
|
||||
Istio has two webhooks: Galley and the sidecar injector.
|
||||
|
@ -38,4 +37,4 @@ will not be able to alter the webhook configurations.
|
|||
and that the certificate chain used by the webhook server is valid. This reduces the errors
|
||||
that can occur before a server is ready or if a server has invalid certificates.
|
||||
|
||||
To try this new feature, refer to the [Istio webhook management task](https://archive.istio.io/v1.4/docs/tasks/security/webhook).
|
||||
To try this new feature, refer to the [Istio webhook management task](https://archive.istio.io/v1.4/docs/tasks/security/webhook).
|
||||
|
|
|
@ -5,5 +5,4 @@ weight: 8
|
|||
icon: blog
|
||||
decoration: dot
|
||||
list_by_publishdate: true
|
||||
test: n/a
|
||||
---
|
||||
|
|
|
@ -4,7 +4,6 @@ description: A new way to manage installation of telemetry addons.
|
|||
publishdate: 2020-06-04
|
||||
attribution: John Howard (Google)
|
||||
keywords: [telemetry,addons,integrations,grafana,prometheus]
|
||||
test: n/a
|
||||
---
|
||||
|
||||
Starting with Istio 1.6, we are introducing a new method for integration with telemetry addons, such as Grafana, Prometheus, Zipkin, Jaeger, and Kiali.
|
||||
|
|
|
@ -5,7 +5,6 @@ subtitle: Configure the IBM Cloud Kubernetes Service Application Load Balancer t
|
|||
publishdate: 2020-05-15
|
||||
attribution: Vadim Eisenberg (IBM)
|
||||
keywords: [traffic-management,ingress,file-mount-credentials,iks]
|
||||
test: no
|
||||
---
|
||||
|
||||
In this blog post I show how to configure the [Ingress Application Load Balancer (ALB)](https://cloud.ibm.com/docs/containers?topic=containers-ingress-about)
|
||||
|
|
|
@ -5,7 +5,6 @@ description: Configuring Wasm extensions for Envoy and Istio declaratively.
|
|||
publishdate: 2020-03-16
|
||||
attribution: "Christian Posta (Solo.io)"
|
||||
keywords: [wasm,extensibility,alpha,operator]
|
||||
test: no
|
||||
---
|
||||
|
||||
As outlined in the [Istio 2020 trade winds blog](/blog/2020/tradewinds-2020/) and more recently [announced with Istio 1.5](/news/releases/1.5.x/announcing-1.5/), WebAssembly (Wasm) is now an (alpha) option for extending the functionality of the Istio service proxy (Envoy proxy). With Wasm, users can build support for new protocols, custom metrics, loggers, and other filters. Working closely with Google, we in the community ([Solo.io](https://solo.io)) have focused on the user experience of building, socializing, and deploying Wasm extensions to Istio. We've announced [WebAssembly Hub](https://webassemblyhub.io) and [associated tooling](https://docs.solo.io/web-assembly-hub/latest/installation/) to build a "docker-like" experience for working with Wasm.
|
||||
|
|
|
@ -5,7 +5,6 @@ publishdate: 2020-02-20
|
|||
attribution: Lei Tang (Google)
|
||||
keywords: [security, secret discovery service, unix domain socket]
|
||||
target_release: 1.5
|
||||
test: n/a
|
||||
---
|
||||
|
||||
In Istio versions before 1.5, during secret discovery service (SDS) execution,
|
||||
|
|
|
@ -6,7 +6,6 @@ publishdate: 2020-04-21
|
|||
attribution: "Christian Posta (Solo.io)"
|
||||
keywords: [istio, sds, mTLS, edge, ingress, gloo, solo.io]
|
||||
draft: true
|
||||
test: n/a
|
||||
---
|
||||
|
||||
[Gloo is an open-source API Gateway](https://docs.solo.io/gloo/latest/) built on Envoy Proxy that highly complements a service mesh like Istio with edge capabilities, such as [request/response transformations](https://docs.solo.io/gloo/latest/guides/traffic_management/request_processing/transformations/), [direct-response actions](https://docs.solo.io/gloo/latest/guides/traffic_management/request_processing/direct_response_action/), and [Open API Spec/Swagger and gRPC discovery](https://docs.solo.io/gloo/latest/installation/advanced_configuration/fds_mode/). This benefits you by having API Gateway capabilities at the edge of your mesh (or multiple clusters of a mesh) without manually adding support for this into the Istio ingress gateway using Lua, etc. [Gloo Enterprise](https://www.solo.io/products/gloo/) supports more sophisticated security edge requirements, such as [OIDC authentication](https://docs.solo.io/gloo/latest/guides/security/auth/oauth/), [OPA authorization](https://docs.solo.io/gloo/latest/guides/security/auth/opa/), [Web Application Fire walling (WAF)](https://docs.solo.io/gloo/latest/guides/security/waf/), rate limiting and others. There is also a custom-auth framework for building your own edge security protocols (common ones like non-standard security handshakes, HMAC, etc) into the ext-auth server that Gloo uses. A lot of Gloo users put Gloo at the edge for North/South concerns and [integrate with Istio for East-West traffic management](https://www.solo.io/blog/using-gloo-as-an-ingress-gateway-with-istio-and-mtls-updated-for-istio-1-1/).
|
||||
|
|
|
@ -5,7 +5,6 @@ description: Istiod consolidates the Istio control plane components into a singl
|
|||
publishdate: 2020-03-19
|
||||
attribution: "Craig Box (Google)"
|
||||
keywords: [istiod,control plane,operator]
|
||||
test: n/a
|
||||
---
|
||||
|
||||
Microservices are a great pattern when they map services to disparate teams that deliver them, or when the value of independent rollout and the value of independent scale are greater than the cost of orchestration. We regularly talk to customers and teams running Istio in the real world, and they told us that none of these were the case for the Istio control plane. So, in Istio 1.5, we've changed how Istio is packaged, consolidating the control plane functionality into a single binary called **istiod**.
|
||||
|
|
|
@ -6,7 +6,6 @@ publishdate: 2020-01-05
|
|||
attribution: Anil Attuluri (Intuit), Jason Webb (Intuit)
|
||||
keywords: [traffic-management,automation,configuration,multicluster,multi-mesh,gateway,federated,globalidentifer]
|
||||
target_release: 1.5
|
||||
test: no
|
||||
---
|
||||
|
||||
At Intuit, we read the blog post [Multi-Mesh Deployments for Isolation and Boundary Protection](/blog/2019/isolated-clusters/) and immediately related to some of the problems mentioned.
|
||||
|
|
|
@ -5,7 +5,6 @@ description: Simplifying Istio upgrades by offering safe canary deployments of t
|
|||
publishdate: 2020-05-19
|
||||
attribution: "John Howard (Google)"
|
||||
keywords: [install,upgrade,revision,control plane]
|
||||
test: n/a
|
||||
---
|
||||
|
||||
Canary deployments are a core feature of Istio. Users rely on Istio's traffic management features to safely control the rollout of new versions of their applications, while making use of Istio's rich telemetry to compare the performance of canaries. However, when it came to upgrading Istio, there was not an easy way to canary the upgrade, and due to the in-place nature of the upgrade, issues or changes found affect the entire mesh at once.
|
||||
|
|
|
@ -5,7 +5,6 @@ publishdate: 2020-03-25
|
|||
attribution: Lei Tang (Google)
|
||||
keywords: [certificate,sidecar]
|
||||
target_release: 1.5
|
||||
test: no
|
||||
---
|
||||
|
||||
{{< boilerplate experimental-feature-warning >}}
|
||||
|
|
|
@ -5,7 +5,6 @@ description: A vision statement and roadmap for Istio in 2020.
|
|||
publishdate: 2020-03-03
|
||||
attribution: Istio Team
|
||||
keywords: [roadmap,security,performance,operator]
|
||||
test: n/a
|
||||
---
|
||||
|
||||
Istio solves real problems that people encounter running microservices. Even
|
||||
|
|
|
@ -5,7 +5,6 @@ description: The future of Istio extensibility using WASM.
|
|||
publishdate: 2020-03-05
|
||||
attribution: "Craig Box, Mandar Jog, John Plevyak, Louis Ryan, Piotr Sikora (Google), Yuval Kohavi, Scott Weiss (Solo.io)"
|
||||
keywords: [wasm,extensibility,alpha,performance,operator]
|
||||
test: n/a
|
||||
---
|
||||
|
||||
Since adopting [Envoy](https://www.envoyproxy.io/) in 2016, the Istio project has always wanted to
|
||||
|
|
|
@ -5,7 +5,6 @@ description: Community partner tooling of Wasm for Istio by Solo.io.
|
|||
publishdate: 2020-03-25
|
||||
attribution: "Idit Levine (Solo.io)"
|
||||
keywords: [wasm,extensibility,alpha,performance,operator]
|
||||
test: n/a
|
||||
---
|
||||
|
||||
[*Originally posted on the Solo.io blog*](https://www.solo.io/blog/an-extended-and-improved-webassembly-hub-to-helps-bring-the-power-of-webassembly-to-envoy-and-istio/)
|
||||
|
|
|
@ -5,7 +5,6 @@ description: Describing the new functionality of Workload Entries.
|
|||
publishdate: 2020-05-21
|
||||
attribution: "Cynthia Coan (Tetrate), Shriram Rajagopalan (Tetrate), Tia Louden (Tetrate), John Howard (Google), Sven Mawson (Google)"
|
||||
keywords: [vm,workloadentry,migration,'1.6',baremetal,serviceentry,discovery]
|
||||
test: no
|
||||
---
|
||||
|
||||
## Introducing Workload Entries: Bridging Kubernetes and VMs
|
||||
|
@ -98,4 +97,4 @@ This creates a new `WorkloadEntry` with a set of labels and an address, and a `S
|
|||
Notice that the `ServiceEntry` can reference both Pods and `WorkloadEntries`, using the same selector. VMs and Pods can now be treated identically by Istio, rather than being kept separate.
|
||||
|
||||
If you were to migrate some of your workloads to Kubernetes, and you choose to keep a substantial number of your VMs, the `WorkloadSelector` can select both Pods and VMs, and Istio will automatically load balance between them. The 1.6 changes also mean that `WorkloadSelector` syncs configurations between the Pods and VMs and removes the manual requirement to target both infrastructures with duplicate policies like mTLS and authorization.
|
||||
The Istio 1.6 release provides a great starting point for what will be possible for the future of Istio. The ability to describe what exists outside of the mesh the same way you do with a Pod leads to added benefits like improved bootstrapping experience. However, these benefits are merely side effects. The core benefit is you can now have VMs, and Pods co-exist without any configuration needed to bridge the two together.
|
||||
The Istio 1.6 release provides a great starting point for what will be possible for the future of Istio. The ability to describe what exists outside of the mesh the same way you do with a Pod leads to added benefits like improved bootstrapping experience. However, these benefits are merely side effects. The core benefit is you can now have VMs, and Pods co-exist without any configuration needed to bridge the two together.
|
||||
|
|
|
@ -10,5 +10,4 @@ aliases:
|
|||
outputs:
|
||||
- html
|
||||
- rss
|
||||
test: n/a
|
||||
---
|
||||
|
|
|
@ -1,5 +1,4 @@
|
|||
---
|
||||
test: no
|
||||
---
|
||||
## Before you begin
|
||||
|
||||
|
|
|
@ -1,8 +1,7 @@
|
|||
---
|
||||
test: no
|
||||
---
|
||||
This is some boilerplate **markdown** _text_.
|
||||
|
||||
{{< text plain >}}
|
||||
A sample nested text block in a boilerplate.
|
||||
{{< /text >}}
|
||||
{{< /text >}}
|
||||
|
|
|
@ -1,7 +1,6 @@
|
|||
---
|
||||
test: n/a
|
||||
---
|
||||
{{< warning >}}
|
||||
The following information describes an experimental feature, which is intended
|
||||
for evaluation purposes only.
|
||||
{{< /warning >}}
|
||||
{{< /warning >}}
|
||||
|
|
|
@ -1,5 +1,4 @@
|
|||
---
|
||||
test: n/a
|
||||
---
|
||||
{{< warning >}}
|
||||
The instructions for using Helm with Tiller do not use secure defaults.
|
||||
|
|
|
@ -1,6 +1,5 @@
|
|||
---
|
||||
headless: true
|
||||
test: n/a
|
||||
---
|
||||
|
||||
This file tells Hugo that the files in this directory tree shouldn't be rendered as normal pages on the site.
|
||||
|
|
|
@ -1,5 +1,4 @@
|
|||
---
|
||||
test: no
|
||||
---
|
||||
* You can use the `kubectl` command to access both the `cluster1` and `cluster2` clusters with the `--context` flag,
|
||||
for example `kubectl get pods --context cluster1`.
|
||||
|
|
|
@ -1,5 +1,4 @@
|
|||
---
|
||||
test: n/a
|
||||
---
|
||||
|
||||
## Reporting vulnerabilities
|
||||
|
|
|
@ -1,5 +1,4 @@
|
|||
---
|
||||
test: no
|
||||
---
|
||||
* Start the [httpbin]({{< github_tree >}}/samples/httpbin) sample.
|
||||
|
||||
|
|
|
@ -1,4 +1,3 @@
|
|||
---
|
||||
test: n/a
|
||||
---
|
||||
This is some boilerplate text.
|
||||
|
|
|
@ -1,5 +1,4 @@
|
|||
---
|
||||
test: no
|
||||
---
|
||||
This is some boilerplate *markdown* _text_.
|
||||
|
||||
|
|
|
@ -1,5 +1,4 @@
|
|||
---
|
||||
test: n/a
|
||||
---
|
||||
{{< warning >}}
|
||||
A warning from a boilerplate
|
||||
|
|
|
@ -1,5 +1,4 @@
|
|||
---
|
||||
test: no
|
||||
---
|
||||
{{< warning >}}
|
||||
A warning from a boilerplate
|
||||
|
|
|
@ -1,5 +1,4 @@
|
|||
---
|
||||
test: no
|
||||
---
|
||||
To see trace data, you must send requests to your service. The number of requests depends on Istio's sampling rate.
|
||||
You set this rate when you install Istio. The default sampling rate is 1%. You need to send at least 100 requests before the first trace is visible.
|
||||
|
@ -7,4 +6,4 @@ To send a 100 requests to the `productpage` service, use the following command:
|
|||
|
||||
{{< text bash >}}
|
||||
$ for i in `seq 1 100`; do curl -s -o /dev/null http://$GATEWAY_URL/productpage; done
|
||||
{{< /text >}}
|
||||
{{< /text >}}
|
||||
|
|
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue