I am using istio 1.9.0.
Only during an issue did I discover that Service Entries are applied at a cluster level even if the namespace is specified in the manifest. This becomes particularly thorny if you have multiple Service Entries in different namespaces for the same hostnames.
I later found the docs that mention the following:
exportTo:
A list of namespaces to which this service is exported. Exporting a
service allows it to be used by sidecars, gateways and virtual
services defined in other namespaces. This feature provides a
mechanism for service owners and mesh administrators to control the
visibility of services across namespace boundaries.
If no namespaces are specified then the service is exported to all
namespaces by default.
The value “.” is reserved and defines an export to the same namespace
that the service is declared in. Similarly the value “*” is reserved
and defines an export to all namespaces.
From here.
Q1.
The docs however explicitly fails to clarify if adding the exportTo=’.’ ensures that a Service Entry in my namespace will always take priority. Is this implied? particularly interested to find some documentation that calls out the expected behaviour.
Q2.
Also how do you go about checking which Service Entry has been applied for the same hostname if multiple exist? How does istio handle this?
The problem is related to ServiceEntry concept design and it's quite complex.
My understanding of the current situation is that one should have an explicitly defined ServiceEntry in the certain namespace to prevent Istio from searching other ServiceEntries in another namespaces for the same host endpoint.
More information about the problem you can find in the issue #13008 :
A ServiceEntry from one namespace can interfere with the traffic of another namespace #13008
The changes was made in the PR #13631 :
Make ServiceEntry follow Sidecar isolation #13631
See the design doc for more details. I'd recommend to read the whole document to see a full picture.
The main point of the change is to implement the following:
Proposed Behavior
Pilot will internally be modified to key Services by a hostname and namespace pair, rather than just hostname. When determining which Services to use for a hostname we will follow this resolution:
If the hostname exists in the client's namespace, use only that namespace's service.
If the hostname exists only in one namespace imported by the Sidecar, use that namespace's service.
Otherwise, if there are multiple namespaces with services, an arbitrary one can be chosen (based on creation timestamp, like other configs).
The end result of this is that while hostnames are not distinct at a global level, any given proxy will have a single unique hostname -> service mapping.
Additionally, a ServiceEntry for an internal service will be rejected if it is created in different namespace. For example, if foo.ns1.svc.cluster.local was defined in namespace ns2, it would be rejected. This prevents the case of a user importing [ns1/, ns2/] and having their requests to foo.ns1.svc.cluster.local hijacked.
Unfortunately I wasn't able to find the final state of the implemented changes for the recent Istio version.
Not having a minimal reproducible example from you doesn't allow me to check if you were facing the implementation flaw or your configuration is a corner case that the change wasn't suppose to solve.
It's sad that current Istio documentation doesn't explain this aspect well enough.
Related
We have deployed the bookinfo sample application on our cluster as means of making sure istio is working correctly and to demo it’s capabilities.
Due to company’s policies we had to change the service names to follow standard convention:
details —> xx-bookinfodetails-app
ratings —> xx-bookinforatings-app
productpage —> xx-bookinfoproductpage-app
reviews (all versions) —> xx-bookinforeviews-app
We have created a gateway and virtualService to route traffic to the first service ProductPage, which in turn is looking for other services (details/reviews) but now the application is “broken” since it is looking for http://details:9080 and http://reviews:9080 but now they don’t exist anymore.
I am new to istio and don’t know how to solve this and create some form of “translation or rewrite” so that internal requests to http://details would be actually forwarded to http://xx-bookinfodetails-app:9080.
I was trying playing with the productpage virtualservice, also tried creating virtualservices for details and reviews.
I’ve tried creating Destination (though not really knowing what would it help with).
I see that there’s something called ServiceEntry but I cannot find any example to handle internal traffic and quite frankly I didn’t really understand when to use SE.
Help would be highly appreciated
Udi
What are the advatages of the jaeger tracing with istio and without istio?
For example with istio it will reduce the latency for collecting the more traces
If you are already using Istio in the deployment, then enabling tracing in it will provide more complete picture of request processing, such as accounting for the time spent in the network between the proxies.
You also don't need to have full tracing instrumentation in your services as long as they pass through certain headers, then Istio can still provide a pretty accurate picture of the traces (but you cannot capture any business specific data in the traces).
Traces generated by Istio will have standardized span names that you can use to reason about the SLAs across the whole infrastructure, whereas explicit tracing instrumentation inside the services can often use different naming schemes, especially when services are written in different languages and using different frameworks.
For the best of both worlds, I would recommend adding instrumentation inside the services for full fidelity, and also enabling tracing in Istio to capture full picture of request execution (and all network latencies).
I have been searching away at this but cannot seem to find a simple example of how to access the ndb datastore from a python microservice which lives in the same application as other non service modules.
What I want to do is access the actual Model classes of the datastore, i.e. Users...and then query on that class from the microservice.
I know you cannot use the google cloud datastore api in app engine standard, but there must be another way, surely?
The same applies to the shared memcache, if I make an API call to an endpoint in a module (no service) from the microservice and set something in memcache at the endpoint, I cannot see that in the microservice. So when Google talk about shared datastore and memcache across everything in the same application including microservices, how do they propose you access it?
I'm sure I'm missing something, just can't find it.
To clarify: the microservice term doesn't mean anything particularly special in GAE with respect to Datastore interaction (or otherwise) - all GAE services/modules are equals from this perspective. What makes a GAE service/module a microservice is simply the functionality it performs, not its implementation or how it uses the infrastructure, see Microservices Architecture on Google App Engine.
All services of the same GAE project/application that access the datastore using the ndb library can do that by default, without any restriction or additional service configurations.
The only trick is that all services referencing a particular entity type must have a consistent view of that entity's model definition. This is a requirement coming from the particular implementation of the ndb client library, not from the datastore itself.
The simplest way to obtain such consistent view is IMHO by sharing the same ndb model definition source file(s), which can be achieved by symlinking the same actual source file(s) (or the directories holding them) across the multiple service/module directories, as described in Sharing entities between App Engine modules.
In other words all your services/modules needing to query/access/reference Users entities one way or the other would actually have the same Users model definition available to do so.
Care must be exercised when deploying changes to the model definitions (be it in different services or even between different versions of the same service) either by:
ensuring backward-compatibility with migration strategies
proper deployment orchestration - i.e. ensuring incompatible versions/services never run simultaneously
The same technique can be used for memcache, in a similar manner: a shared source code file would export the definitions of memcache keys for the memcached values that need to be shared across services. Or, better yet, provide actual read/write functions for the corresponding data, to ensure not only that the data is stored under the right keys, but it also has the matching format.
With such shared code in place the memcached data representing certain pieces of information becomes shared across the same app's services/modules (again, regardless of them being microservices or not). Almost as good as the info shared via the datastore, except without transaction support to guarantee consistency.
I am evaluating WSO2 G-REG and would like to add additional attributes to end points (that I initially intend to use for documentation purposes and later on for automation).
I do for instance have one (or possible multiple) "native" endpoint that the service is deployed with in container(s) and in addition to them several "virtualized" endpoints for instance in other network segments (WAN, DMZ...) created by XML gateways and "wired to" the native endpoint(s).
To support this I would like attributes that allow me to specify things like network segment and what "native endpoint(s)" that a "virtual endpoint" is "wired to" etc.
What part of the documentation covers this? Do anybody have some XML snippet that shows how to do it?
I would later like to try adding automation that pushes information to the right Gateway to create the virtual endpoints (perhaps tied to a special like cycle stage transition)... but that is a later challenge...
Endpoints are managed by a handler (org.wso2.carbon.registry.extensions.handlers.EndpointMediaTypeHandler). If you want to add custom attributes, you will have to extend this with your own.
Thanks,
Senaka.
I'am wondering if two Web Services can have the same targetnamespace. Or is it discouraged to use the same tns multiple times and what is the reason for this limitation?
Technically you can have both the webservices have the same target namespace. But namespaces package logically related set of items together. I wonder why you would like to use the same namespace.