I currently use the fabric8 API to read contents of PODs, Services etc.
KubernetesClient client = new DefaultKubernetesClient();
client.configMaps().withName("ConfigMapName");
Is there a way to retrieve contents of HTTPProxy from httpproxies of api group projectcontour.io?
Thanks in advance!!!
HTTPProxy seems to be a Custom Resource. Kubernetes Client provides a Typed API (where you need to provide POJOs for your Custom Resource) and a Typeless API(manipulation of Custom Resouces using raw HashMaps). Here is an example on how you can do this using the Typeless API:
try (KubernetesClient client = new DefaultKubernetesClient()) {
CustomResourceDefinitionContext httpProxyContext = new CustomResourceDefinitionContext.Builder()
.withGroup("projectcontour.io") // <- Group of Custom Resource
.withVersion("v1") // <- Version of Custom Resource
.withPlural("httpproxies") // <- Plural form as specified in CRD
.withScope("Namespaced") // <- Whether Custom Resource is Cluster Scoped or Namespaced
.build();
// List all HTTPProxies
Map<String, Object> httpProxyList = client.customResource(httpProxyContext).list("ns1");
// Get a specific HTTPProxy
Map<String, Object> myHttpProxy = client.customResource(httpProxyContext).get("ns1", "tls-example");
}
You may choose whatever approach you think fits your needs. If interested you can probably check out my blogs about these approaches in detail:
Handling Kubernetes Custom Resources in Java using Fabric8 Kubernetes Client: Part-1(Typeless)
Handling Kubernetes Custom Resources in Java using Fabric8 Kubernetes Client: Part-2(Typed)
Related
I am using skuber 2.4.0.
Is there a way to use the skuber client.delete an object in a specific namespace?
I understand that when I create a client I can specify a namespace.
But for example when creating a job you can specify any namespace in the metadata.
Seems weird to need to create a new client just for deletion.
I suggest you open an issue in the github repo for further help.
https://github.com/hagay3/skuber/issues
EDIT:
Namespaces API is now available in version 2.7.6
It's possible to provide namespace in every client endpoint.
https://github.com/hagay3/skuber/releases/tag/v2.7.6
OLD ANSWER:
Regarding your question, you can use the following method:
def usingNamespace(newNamespace: String): KubernetesClient
https://github.com/hagay3/skuber/blob/master/client/src/main/scala/skuber/api/client/KubernetesClient.scala#L366
example:
https://github.com/hagay3/skuber/blob/master/client/src/it/scala/skuber/NamespaceSpec.scala#L53
I am currently looking into deploying Traefik/Træfik on our service fabric cluster.
Basically I have a setup where I have any number of Applications (services), defined with a tenant name and each of these services is in fact a separate Web UI.
I am trying to figure out if I can configure a single frontend to target a backend so I don't have to define a new frontend each time I deploy a new UI app. Something like
[frontend.tenantui]
rule = "HostRegexp:localhost,{tenantName:[a-z]+}.example.com"
backend = "fabric:/WebApp/{tenantName}"
The idea is to have it such that I can just deploy new UI services without updating the frontend configuration.
I am currently using the Service Fabric provider for my backend services, but I am open to using the file provider or something else if that is required.
Update:
The servicemanifset contains labels, so as to let traefik create backends and frontends.
The labels are defined for one service, lets call it WebUI as an example. Now when I deploy an instance of WebUI it gets a label and traefik understands it.
Then I deploy ANOTHER instance with a DIFFERENT set of parameters, its still the WebUI service and it uses the same manifest, so it gets the same labels, and the same routing. But what I would really want was to let it have a label containing some sort of rule so I could route to the name of the service instance (determine at runtime not design time). Specifically I would like for the runtime part to be part of the domainname (thus the suggestion of a HostRegexp style rule)
I don't think it is possible to use the matched group from the HostRegexp to determine the backend.
A possibility would be to use the Property Manager API to dynamically set the frontend rule for the service instance after creating it. Also, see this for a complete example on using the API.
Context
My micro-services application is based on spring-cloud: a zuul gateway is configured in front of two micro-services: service-a and service-b.
One of my API requires that service-a requests service-b; I use feign for that.
Zuul send X-FORWARDED-* headers to the services, for them to rewrite the HATEOAS links correctly (when the services are configured with ForwardedHeaderFilter).
My problem is that the services communicate with each other using Feign, which relies on Hystrix.
Hystrix creates a new thread for each request (we don't use the SEMAPHORE config), so the request in Spring's RequestContextHolder is lost in the Feign request from service-a to service-b, I can't enrich the feign request with an feign interceptor anymore since the original request is lost.
Some potential solutions
Forwarding authorization token is now supported directly by Spring with the parameter hystrix.shareSecurityContext: true
There isn't any "out of the box" configuration to have Hystrix shares the request between threads.
A solution could be to implement my own HystrixConcurrencyStrategy, which is a class from netflix.hystrix.
My latest find is this Pull Request that has been sent to spring-cloud-netflix, but unfortunately not integrated.
I can try to copy the code of the Pull request, and create a bean, just as what "eacdy" wrote:
#Bean
public RequestAttributeHystrixConcurrencyStrategy hystrixRequestAutoConfiguration() {
return new RequestAttributeHystrixConcurrencyStrategy();
}
Is there an easier solution to forward the headers from Zuul with Hystrix?
I suppose that what I am trying to do is very standard when using Zuul, Hystrix, and HATEOAS micro-services that communicate with each other, so maybe there is something that exists already (and that I couldn't find)?
Thanks !
I thought it was quite a common thing to achieve, but after a lot of research, I couldn't find a way to forward the X-FORWARDED-* headers automatically with Feign and Hystrix.
So, I looked for another solution, which works and is quite clean:
In the Feign client from service-a to service-b, I declared a specific configuration "ServiceBFeignConfig", which, in addition to forward the token, also add the X-Forwarded-* headers corresponding to the gateway:
#Configuration
public class ServiceBFeignConfig {
#Autowired
private ApplicationProperties applicationProperties;
#Bean
public RequestInterceptor requestTokenBearerInterceptor() {
return new RequestInterceptor() {
#Override
public void apply(RequestTemplate requestTemplate) {
OAuth2AuthenticationDetails details =
(OAuth2AuthenticationDetails) SecurityContextHolder.getContext().getAuthentication().getDetails();
requestTemplate.header("Authorization", "bearer " + details.getTokenValue());
if (applicationProperties.getFeign().getGatewayEnabled()) {
requestTemplate.header("X-Forwarded-Host", applicationProperties.getFeign().getGatewayHost());
requestTemplate.header("X-Forwarded-Port", applicationProperties.getFeign().getGatewayPort());
requestTemplate.header("X-Forwarded-Proto", applicationProperties.getFeign().getGatewayProtocol());
requestTemplate.header("X-Forwarded-Prefix", applicationProperties.getFeign().getServiceBPrefix());
}
}
};
}
}
You can see that the gateway host and port is configured in the properties files (that is served by Spring Cloud Config in my case). The service-b prefix is also set in these files.
These headers are only added if the "gatewayEnabled" property is set in the properties files.
You have to ignore this configuration from the component scan of Spring Boot, even if it needs the #Configuration annotation, so put it in a "ignorescan" package, and on your main Spring boot class, use:
#ComponentScan(basePackages = { "com.myservice" }, excludeFilters = #ComponentScan.Filter(type = FilterType.REGEX, pattern = "com.myservice.ignorescan.*"))
At the end, the Forward headers will be added if you have the gatewayEnabled set to true, and the API call to the gateway get the correct HATEOAS links.
Is there a recommended way for injecting / accessing the application Typesafe config instance from within a Lagom service interface (ie, the trait, not Impl)?
The use case I am thinking of is for the creation of a request header filter that depends on a configurable value (like, an env specific secret) and injecting it via a constructor argument.
final override def descriptor: Descriptor = {
import Service._
named("some-service")
.withCalls(
pathCall("/health", healthCheck),
)
.withHeaderFilter(new CustomerHeaderFilter(config))
}
Unfortunately, from within the descriptor function, there is no readily exposed reference to the config. I have tried including as an abstract field on the service but this seems to cause Lagom to bomb out and complain that the field does not generate a service.
Is there a recommended way to do this or do I essentially have to call ConfigFactory.load()?
Currently using Lagom 1.4.5 + Scala - thanks!
I am working on Vert.x Service Discovery registering HttpEndPoints. Is there a way to specify ProxyOptions when publishing HttpEndPoint to service discovery?
Thanks,
-Rajani
You don't provide the options when creating the record but when retrieving the service reference.
ServiceReference reference = discovery.getReferenceWithConfiguration(record, new HttpClientOptions()
.setProxyOptions(proxyOptions)
.toJson());
This explained in the retrieving a service reference section of the documentation:
When retrieving a service reference you can pass a JsonObject used to
configure the service object.