Skip to content

Commit 948d3e2

Browse files
author
github-actions
committed
Merge tag '1.29.0' into tetratefips-release-1.29
Istio release 1.29.0
2 parents 67678b9 + 2300e24 commit 948d3e2

6,070 files changed

Lines changed: 862313 additions & 20 deletions

File tree

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

‎.devcontainer/devcontainer.json‎

Lines changed: 33 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,33 @@
1+
{
2+
"name": "istio build-tools",
3+
"image": "gcr.io/istio-testing/build-tools:release-1.29-48686f08d4dc58cbcc68335f8f71c76fca6cac9e",
4+
"privileged": true,
5+
"remoteEnv": {
6+
"USE_GKE_GCLOUD_AUTH_PLUGIN": "True",
7+
"BUILD_WITH_CONTAINER": "0",
8+
"CARGO_HOME": "/home/.cargo",
9+
"RUSTUP_HOME": "/home/.rustup"
10+
},
11+
"features": {
12+
"ghcr.io/devcontainers/features/docker-outside-of-docker:1": {},
13+
"ghcr.io/mpriscella/features/kind:1": {}
14+
},
15+
"customizations": {
16+
"vscode": {
17+
"extensions": [
18+
"golang.go",
19+
"rust-lang.rust-analyzer",
20+
"eamodio.gitlens",
21+
"zxh404.vscode-proto3",
22+
"ms-azuretools.vscode-docker",
23+
"redhat.vscode-yaml",
24+
"IBM.output-colorizer"
25+
],
26+
"settings": {
27+
"files.eol": "\n",
28+
"go.useLanguageServer": true,
29+
"go.lintTool": "golangci-lint"
30+
}
31+
}
32+
}
33+
}

‎.gitattributes‎

Lines changed: 16 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,16 @@
1+
*.descriptor linguist-generated=true
2+
*.descriptor -diff -merge
3+
*.descriptor_set linguist-generated=true
4+
*.descriptor_set -diff -merge
5+
*.pb.html linguist-generated=true
6+
*.pb.go linguist-generated=true
7+
*.gen.go linguist-generated=true
8+
*.gen.yaml linguist-generated=true
9+
*.gen.json linguist-generated=true
10+
*_pb2.py linguist-generated=true
11+
manifests/charts/**/profile*.yaml linguist-generated=true
12+
go.sum merge=union
13+
vendor/** linguist-vendored
14+
common/** linguist-vendored
15+
archive/** linquist-vendored
16+
**/vmlinux.h linquist-vendored

‎.github/.copilot/domain_knowledge/integration_test_framework.md‎

Lines changed: 125 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,125 @@
1+
# Istio Integration Test Framework
2+
3+
The Istio integration test framework (`pkg/test/framework`) provides a robust, extensible foundation for writing, running, and managing integration and end-to-end tests for Istio. It orchestrates test environments, manages resources, and provides utilities for common testing patterns across multiple clusters and platforms.
4+
5+
## Overview
6+
7+
The framework enables developers to write expressive, reliable, and maintainable tests for Istio features and behaviors. It abstracts away environment setup, resource lifecycle, and multi-cluster orchestration, allowing test authors to focus on test logic and assertions.
8+
9+
## Architecture
10+
11+
- **Test Suite**: Organizes and runs groups of related tests, handling setup and teardown.
12+
- **Test Context**: Provides per-test context, including access to resources, configuration, and logging.
13+
- **Resource Management**: Handles the lifecycle of test resources (e.g., clusters, namespaces, Istio components).
14+
- **Labeling and Selection**: Supports labeling tests and suites for selective execution.
15+
- **Environment Abstraction**: Supports running tests on different environments (Kubernetes, native, etc.).
16+
- **Logging and Telemetry**: Integrates with Istio's logging and tracing for observability.
17+
18+
## Implementation Details
19+
20+
### Key Patterns
21+
22+
#### Defining and Running a Test Suite
23+
24+
```go
25+
// From pkg/test/framework/suite.go
26+
func TestMain(m *testing.M) {
27+
framework.NewSuite("my_suite").
28+
Label(label.CustomSetup).
29+
Setup(mySetupFunction).
30+
Run()
31+
}
32+
```
33+
34+
#### Writing a Test
35+
36+
```go
37+
// From pkg/test/framework/test.go
38+
framework.NewTest(t).
39+
Label(label.CustomSetup).
40+
Run(func(ctx framework.TestContext) {
41+
// Test logic here
42+
})
43+
```
44+
45+
#### Accessing Test Context
46+
47+
```go
48+
// From pkg/test/framework/testcontext.go
49+
func MyTest(ctx framework.TestContext) {
50+
cluster := ctx.Clusters().Default()
51+
// Use cluster to deploy resources, run checks, etc.
52+
}
53+
```
54+
55+
#### Resource Management
56+
57+
```go
58+
// From pkg/test/framework/resource.go
59+
ns := namespace.NewOrFail(ctx, namespace.Config{
60+
Prefix: "test",
61+
Inject: true,
62+
})
63+
defer ns.Delete()
64+
```
65+
66+
### Component Flow
67+
68+
1. **Suite Initialization**: `TestMain` initializes the suite, sets up environments, and registers setup/teardown hooks.
69+
2. **Test Registration**: Individual tests are registered with labels and requirements.
70+
3. **Environment Setup**: The framework provisions clusters, namespaces, and Istio components as needed.
71+
4. **Test Execution**: Each test runs in isolation, with access to a `TestContext` for resource management and assertions.
72+
5. **Teardown**: Resources are cleaned up and logs are collected.
73+
74+
## Key Files
75+
76+
- `pkg/test/framework/suite.go`: Test suite orchestration and lifecycle.
77+
- `pkg/test/framework/test.go`: Test definition and execution.
78+
- `pkg/test/framework/testcontext.go`: Test context and resource access.
79+
- `pkg/test/framework/runtime.go`: Runtime environment management.
80+
- `pkg/test/framework/resource.go`: Resource lifecycle and utilities.
81+
- `pkg/test/framework/logging.go`: Logging integration.
82+
- `pkg/test/framework/operations.go`: Test context creation and test runner entrypoints.
83+
84+
## Examples
85+
86+
### Example: Simple Integration Test
87+
88+
```go
89+
// From pkg/test/framework/integration/main_test.go
90+
func TestExample(t *testing.T) {
91+
framework.NewTest(t).
92+
Run(func(ctx framework.TestContext) {
93+
// Deploy resources, run checks, etc.
94+
})
95+
}
96+
```
97+
98+
### Example: Multi-Cluster Test
99+
100+
```go
101+
// From pkg/test/framework/testcontext.go
102+
func TestMultiCluster(ctx framework.TestContext) {
103+
for _, c := range ctx.Clusters().Primaries() {
104+
// Deploy and validate on each primary cluster
105+
}
106+
}
107+
```
108+
109+
## Best Practices
110+
111+
- Use labels to categorize and filter tests (e.g., `label.CustomSetup`, `label.Flaky`).
112+
- Always clean up resources using `defer` or test context cleanup hooks.
113+
- Use the provided resource and environment abstractions instead of direct Kubernetes API calls.
114+
- Prefer `NewTest` and `NewSuite` for test and suite setup to ensure consistent lifecycle management.
115+
- Leverage the logging and telemetry integration for debugging and observability.
116+
117+
## Related Components
118+
119+
- [istioctl_commands.md](istioctl_commands.md): CLI for interacting with Istio, often used in tests.
120+
- [krt_package.md](krt_package.md): Declarative controller runtime, sometimes tested via the framework.
121+
- [pilot_push_context.md](pilot_push_context.md): Core data structure for configuration, often validated in integration tests.
122+
123+
---
124+
125+
This file should be updated as the test framework evolves and new patterns or utilities are introduced.

‎.github/.copilot/domain_knowledge/istio_analysis_messages.md‎

Lines changed: 105 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,105 @@
1+
# Istio Analysis Messages
2+
3+
This document explains Istio's Analysis messages: what they are, how users can access them, and how to add new analyzers to the system.
4+
5+
## Introduction
6+
7+
Istio Analysis messages are diagnostic outputs produced by static and runtime analyzers that inspect Istio configuration and environment. They help users identify misconfigurations, potential issues, and best practice violations before they impact the mesh.
8+
9+
## Conceptual Overview
10+
11+
- **Analysis messages** are generated by analyzers that scan Istio resources (YAML manifests, live cluster state, etc.).
12+
- Each message includes a code, severity, resource reference, and a human-readable description.
13+
- Analysis can be run as part of `istioctl analyze`, during installation, or via the Istio Operator.
14+
- Analyzers are modular and can be extended by contributors.
15+
16+
## Implementation Architecture
17+
18+
1. **Analyzer Registration**: Analyzers are registered in the analysis framework.
19+
2. **Input Gathering**: The framework collects resources from files, clusters, or both.
20+
3. **Analysis Execution**: Each analyzer inspects the resources and emits messages.
21+
4. **Message Aggregation**: Messages are collected, deduplicated, and presented to the user.
22+
23+
### Key Relationships
24+
- Analyzers implement the `analysis.Analyzer` interface.
25+
- The analysis framework orchestrates analyzer execution and message collection.
26+
- Messages are instances of `diag.Message`.
27+
28+
## Code Implementation
29+
30+
### Accessing Analysis Messages
31+
32+
Users can access analysis messages in several ways:
33+
34+
#### 1. Via istioctl
35+
36+
```bash
37+
istioctl analyze -A
38+
```
39+
- Analyzes all namespaces in the current cluster context and prints messages to stdout.
40+
41+
#### 2. During Installation
42+
43+
- `istioctl install` and `istioctl upgrade` run analysis by default and display warnings before applying changes.
44+
45+
#### 3. In CI/CD
46+
47+
- Integrate `istioctl analyze` into pipelines to catch issues before deployment.
48+
49+
### Adding a New Analyzer
50+
51+
1. **Implement the Analyzer Interface**
52+
53+
```go
54+
// From istioctl/pkg/analyze/analysis.go
55+
// Analyzer interface
56+
type Analyzer interface {
57+
Metadata() Metadata
58+
Analyze(Context)
59+
}
60+
```
61+
62+
2. **Define Metadata**
63+
64+
```go
65+
// From istioctl/pkg/analyze/metadata.go
66+
type Metadata struct {
67+
Name string
68+
Description string
69+
Inputs collection.Names
70+
}
71+
```
72+
73+
3. **Emit Messages**
74+
75+
```go
76+
// From istioctl/pkg/analyze/context.go
77+
ctx.Report(collection, diag.NewMessage(...))
78+
```
79+
80+
4. **Register the Analyzer**
81+
82+
- Add your analyzer to the list in `istioctl/pkg/analyze/all/all.go`.
83+
84+
## Key Interfaces/Models
85+
86+
- `analysis.Analyzer`: Analyzer contract (`istioctl/pkg/analyze/analysis.go`)
87+
- `diag.Message`: Analysis message structure (`istio.io/istio/pkg/config/analysis/diag/message.go`)
88+
- `Context`: Used to emit messages (`istioctl/pkg/analyze/context.go`)
89+
90+
## Example Use Cases
91+
92+
- Detecting missing gateways referenced by VirtualServices
93+
- Warning about deprecated API usage
94+
- Identifying conflicting DestinationRules
95+
96+
## Best Practices
97+
98+
- Make messages actionable and clear; include resource references.
99+
- Use appropriate severity (Error, Warning, Info).
100+
- Avoid false positives by checking for all required context.
101+
- Add tests for new analyzers in `istioctl/pkg/analyze/testdata/`.
102+
103+
## Related Components
104+
105+
- [istioctl analyze](istioctl_commands.md): CLI for running analyzers

‎.github/.copilot/domain_knowledge/istio_tags_and_revisions.md‎

Lines changed: 90 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,90 @@
1+
# Istio Tags and Revisions
2+
3+
This document explains Istio's Tags and Revisions: their role in orchestration and xDS generation, and how users can create, update, and delete tags and revisions.
4+
5+
## Introduction
6+
7+
Istio uses the concepts of **Revisions** and **Tags** to manage multiple control plane versions and orchestrate progressive rollout, upgrades, and traffic control. These mechanisms allow users to run multiple Istio control planes in a cluster and direct workloads to specific versions or configurations.
8+
9+
## Conceptual Overview
10+
11+
- **Revision**: A unique identifier (e.g., `istio-system/revision-1-20-2`) for a specific Istio control plane deployment. Each revision manages its own set of webhooks, configuration, and xDS resources.
12+
- **Tag**: An alias that points to a specific revision. Tags provide a stable reference for workloads and can be updated to point to new revisions without changing workload labels.
13+
- Both tags and revisions influence which control plane instance orchestrates a workload and which xDS configuration it receives.
14+
15+
## Implementation Architecture
16+
17+
1. **Revisioned Control Planes**: Multiple Istiod deployments run in the cluster, each with a unique `--revision` flag.
18+
2. **Webhook Selection**: Workloads are injected with sidecars by the webhook matching their `istio.io/rev` label (revision or tag).
19+
3. **xDS Generation**: Each Istiod instance generates xDS resources only for workloads labeled with its revision or a tag pointing to it.
20+
4. **Tag Management**: Tags are managed as custom resources and can be created, updated, or deleted to control traffic and upgrade flows.
21+
22+
### Key Relationships
23+
- Workload labels (`istio.io/rev`) determine which revision or tag manages injection and xDS.
24+
- Tags are mapped to revisions; updating a tag can shift many workloads to a new control plane version atomically.
25+
- xDS resources are isolated per revision/tag, ensuring safe canary and progressive rollouts.
26+
27+
## Code Implementation
28+
29+
### Creating, Updating, and Deleting Tags and Revisions
30+
31+
#### 1. Creating a Revision
32+
- Deploy Istiod with a unique revision:
33+
34+
```bash
35+
istioctl install --set revision=canary
36+
```
37+
- This creates a new control plane and associated webhooks.
38+
39+
#### 2. Creating a Tag
40+
- Create a tag pointing to a revision:
41+
42+
```bash
43+
istioctl tag set prod --revision=canary
44+
```
45+
- This creates a `prod` tag that points to the `canary` revision.
46+
47+
#### 3. Updating a Tag
48+
- Change the tag to point to a different revision:
49+
50+
```bash
51+
istioctl tag set prod --revision=1-21-0
52+
```
53+
- All workloads labeled with `istio.io/rev=prod` will now be managed by the new revision.
54+
55+
#### 4. Deleting a Tag
56+
57+
```bash
58+
istioctl tag remove prod
59+
```
60+
- Removes the tag and its associated webhook.
61+
62+
#### 5. Deleting a Revision
63+
- Remove the Istiod deployment and associated resources for a revision:
64+
65+
```bash
66+
istioctl uninstall --revision=canary
67+
```
68+
69+
## Key Interfaces/Models
70+
71+
- Tag CRD: `manifests/charts/istio-control/istio-discovery/templates/revision-tags.yaml`
72+
- Tag CLI: `istioctl/pkg/tag/tag.go`
73+
- Revision detection: `pkg/revisions/tag_watcher.go`
74+
75+
## Example Use Cases
76+
77+
- **Canary Upgrade**: Deploy a new revision, create a tag, and gradually move workloads to the new version by updating the tag.
78+
- **Blue/Green Deployment**: Use tags to switch traffic between two revisions with minimal disruption.
79+
- **Rollback**: Quickly revert a tag to point to a previous revision if issues are detected.
80+
81+
## Best Practices
82+
83+
- Use tags for stable references in production; avoid labeling workloads directly with revision names unless necessary.
84+
- Always test new revisions with a small set of workloads before updating tags cluster-wide.
85+
- Clean up unused revisions and tags to avoid confusion and resource waste.
86+
- Automate tag updates in CI/CD for safe, repeatable rollouts.
87+
88+
## Related Components
89+
90+
- [istioctl tag](istioctl_commands.md): CLI for managing tags

0 commit comments

Comments
 (0)