Number of Sprints in Releases

There's no mandated relationship between Sprints and releases. A team may release multiple times in a Sprint, perhaps as each Product Backlog Item is complete. However, in some environments, releasing to stakeholders is a more costly activity, so the team may choose to get feedback on their work through alternative methods and release when the added value to the product since the last release is close to or exceeds the cost of releasing.

Is it acceptable that there will be only 1 sprint (2 weeks duration) in a release? Does it always have to be more than 1? 

Think of it the other way round. The Scrum Guide says: "Multiple Increments may be created within a Sprint".

There must be at least one Increment of immediately usable quality produced every Sprint, so the assumptions made in its development can be empirically validated.

The word "release" appears twice in the Scrum Guide.  Both are in the section that describes the increment.

The Sprint Review should never be considered a gate to releasing value.

If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review.

Notice that neither of them is actually speaking to how/when to release.  It is up to the organization on how often something is released to the stakeholders.  I have worked with teams that released updates to production multiple times a day using Continuous Integration/Continuous Delivery (CI/CD). One team would bet each other on how many times they released during a Sprint. At the time I left that organization, their record was 33 in a 2 week Sprint. 

The answer to your question needs to come from your organization and team. Here are some questions you might want to ask. How much risk is acceptable?  Are there any regulatory restrictions? Can we recover quickly and easily from changes? What is the meaning of life?  (Ok, you can skip the last one but if you know it, please share.)