```

## Other Reference

The framework for this implementation of the CNI plugin is based on the
[containernetworking sample plugin](https://github.com/containernetworking/plugins/tree/main/plugins/sample)

The details for the deployment & installation of this plugin were pretty much lifted directly from the
[Calico CNI plugin](https://github.com/projectcalico/cni-plugin).

  held off after the release. Hiding/Showing documentation does not require TOC approval.
* Cases for other API changes require TOC approval
    * Simple `meshConfig` changes have been approved in the past. Functionality should not be enabled by default.
* For large API changes, 2 members of the TOC must approve the PR before release manager approval in the release branch

  // serving this Ingress resource, by a transitive connection
  // (controller -> IngressClass -> Ingress resource). Although the
  // `kubernetes.io/ingress.class` annotation (simple constant name) was never
  // formally defined, it was widely supported by Ingress controllers to create
  // a direct binding between Ingress controller and Ingress resources. Newly

Next steps:
  * Deploy an HTTP Gateway: https://istio.io/latest/docs/tasks/traffic-management/ingress/ingress-control/

#-----------------------------------------------------------------------------
include tests/integration/tests.mk

#-----------------------------------------------------------------------------
# Target: bookinfo sample
#-----------------------------------------------------------------------------

export BOOKINFO_VERSION ?= 1.18.0

.PHONY: bookinfo.build bookinfo.push

bookinfo.build:
	@prow/buildx-create

// state of a system, especially if the node that hosts the pod cannot contact the control
// plane.
message PodStatus {
  // The phase of a Pod is a simple, high-level summary of where the Pod is in its lifecycle.
  // The conditions array, the reason and message fields, and the individual container status
  // arrays contain more detail about the pod's status.

state of the world. It is regenerated (usually partially) on each configuration push (more on this below). Due to being a snapshot, most lookups are lock-free.

`PushContext` is built up by querying the above layers. For some simple use cases, this is as simple as storing something like `configstore.List(SomeType)`; in this case, the only difference from directly exposing the configstore is to snapshot the current state. In other cases, some pre-computations and indexes are computed to make...

github.com/coreos/go-oidc/v3 v3.10.0/go.mod h1:5j11xcw0D3+SGxn6Z/WFADsgcWVMyNAlSQupk0KK3ac=
github.com/coreos/go-semver v0.2.0/go.mod h1:nnelYz7RCh+5ahJtPPxZlU+153eP4D4r3EedlOD2RNk=
github.com/coreos/go-semver v0.3.0/go.mod h1:nnelYz7RCh+5ahJtPPxZlU+153eP4D4r3EedlOD2RNk=
github.com/coreos/go-semver v0.3.1 h1:yi21YpKnrx1gt5R+la8n5WgS0kCrsPp33dmEyHReZr4=
github.com/coreos/go-semver v0.3.1/go.mod h1:irMmmIw/7yzSRPWryHsK7EYSg09caPQL03VsM8rvUec=

</a>

---

Istio is an open source service mesh that layers transparently onto existing distributed applications. Istio’s powerful features provide a uniform and more efficient way to secure, connect, and monitor services. Istio is the path to load balancing, service-to-service authentication, and monitoring – with few or no service code changes.

This can be reading from Kubernetes and writing other objects back, writing to proxies over XDS, etc.

Unfortunately, writing controllers is very error prone, even for seemingly simple cases.
To work around this, Istio has a variety of abstractions meant to make writing controllers easier.

## Clients