I read official and non official documentation, googled it many times, but still don't understand.
How API Kubernetes version corresponds to Kubernetes version? So, we have Kubernetes 1.22 version and which API does it have? If we upgrade K8s version, will API version be upgraded as well or k8s upgrades API version regardless of server version?
Each k8’s versions have different kubernetes API versions, API Versioning.
If we update the k8’s versions then we need to update its new API versions too then only we don’t have any breakages in the service or else we can roll back to previous k8’s versions.
We have Kubernetes 1.22 version and which API does it have? In v1.22 some APIs got deprecated for detailed information of APIs.Refer this doc for API changes in v1.22.
Related
Used the template provided here :- https://github.com/3scale/3scale-amp-openshift-templates/blob/master/amp/amp.yml
Under integration tab , i am unable to see the option for APICast self managed gateway option.
From the graphics I would assume the version you installed is 2.3 or lower.
My suggestion is to try with the latest stable template (2.8)
I am using NServiceBus as middelware for an asp.net core 3.0 API. I already configured the service in my API using NServiceBus version 7.2 because the documentation for that on the website of particular is amazing. Saddly I have a probleem because i got a licence for an older version of NServiceBus versions until version 7.1.x are valid.
my question is: is there a recomendition for configuring NServiceBus in asp.net core using Versions 7.1.x?
One option is to use an external container and configure the endpoint to use it. Take a look at the sample available in the README of the MSDependencyInjection container.
The same thing can be achieved, with very similar code using one of the supported IoC container: https://docs.particular.net/nservicebus/dependency-injection/#internally-managed-mode-using-a-third-party-container
I've been looking into options of getting a newer version of Kubernetes in both AKS and ACS, but it seems the supported versions as of now are 1.7.7, 1.7.9, 1.8.1 and 1.8.2 (output of command az aks get-versions).
Since support for Azure is being upgraded continuously judging by the release notes of the latest version (https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.9.md#azure-1) I was wondering if these versions will be available in ACS and / or AKS soon.
I realise that v1.9 is only out for 2 days now, I was looking at v1.8.5 at first :)
Although there is no official dates as of now on when higher versions will be available Microsoft is highly invested and committed to AKS and ACS so I honestly would not be surprised if the versioning update comings shortly. In fact the updated doc was updated just a month ago so we are constantly pushing updates :)
https://learn.microsoft.com/en-us/azure/aks/tutorial-kubernetes-upgrade-cluster
You could always post the versioning question on this above doc too as the doc owners might have more information they are able to share
Is it possible to have multiple versions of service(s) deployed in production at the same time. From my assumption, this should be pretty common pattern for microservice/api based projects or mobile projects. I want to know how do you do it and what are common pattern in industry for this kind of problems. It would be helpful if your answers around AWS environment or Kubernetes environment.
Thanks in Advance.
Is it possible to have multiple versions of service(s) deployed in production at the same time
Yes, it is possible. The idea is to keep all used microservices in production (v1, v2 ...) at the same time and to bring down the versions that are not used anymore. For this, you should somehow know when a version is not used anymore.
AFAIK, you have to options:
For every new version you make a new endpoint (like /v2/someApiCall) that is connected to the same (now upgraded) microservice and gradually instruct clients to use the new endpoind; when the old endpoint is not used anymore you deleted it; this is the preferred way.
For every new version you make a new microservice that share the same persistence with the old microservice; you should avoid the use of this solution; Netflix uses this strategy in rare occasions when the cost of changing old consumers is too high.
You can read more at page 62 from Building microservices by Sam Newman.
With AWS API Gateway you could deploy multiple versions of your code and switch between them from the mapping templates, as explained here. You might also want to look into stage variables.
Assuming your are exposing services over An HTTP REST API, the general standard is to always base line your service urls with a version.
Eg,
/v1/account/getUserInfo
If you need to release a new version, expose it over:
/v2/account/getUserInfo
Where v2 can run over a different branch of the codebase.
I have blogged about this: Multi-version Service Discovery using Spring Cloud Netflix Eureka and Ribbon, focussed on Spring Cloud Netflix components / libraries though.
But the idea is to deploy a new version of the artifact / binary in a new host / VPS / Container and have the service register with a registry server (Eureka, Consul, ....) and include metadata about the API versions it supports (v1, v2, ...). Client apps would discover which host / container / ... serves the API version needed.
This is my first question ever in Stack-Overflow!
I am beginner in JIRA. So I wanted to know if there is any stable platform to connect from Java to JIRA without using REST API?
Can I use native Java libraries or any other additional libraries to connect to JIRA?
Yup, atlassian created jira-rest-java-client but doesn't "formally" support it...but is open source...last update was 2014-10-09...so seems maintained.
There is also the SOAP services, which are deprecated but still supported in JIRA 6. They provide instructions on how to build a SOAP client. They'll be phased out, replaced by the REST endpoints, moving forward.