[Sorry in advance for the long explanation, but you've asked good questions about a complex topic.]
Asymmetric encryption uses a keypair consisting of a public and private key; each pair of keys are generated together at the same time.
Asymmetric means "not the same". In cryptography, we use it to mean "What the public key of a keypair encrypts, only the corresponding private key can decrypt." The pair of keys are mathematically related to each other, but knowing the public key does not enable anyone to figure out the private key. You can think of it this way: the public key lets you create a math equation so hard that only the private key can solve it.
Asymmetric cryptographic algorithms allow me to publish my public key, and then anyone can use it to encrypt data. But only my private key can decrypt the message encrypted with my public key. And when I say publish a public key, I mean just that -- the encryption is so safe I can literally paint my public key on a billboard if I want.
The public key is only half of my keypair. What do I do with my private key? I must keep it secret. Otherwise, anyone with my private key can read those secret messages meant only for me.
When do I create a keypair? Obviously I have to create it and "publish" my public key before you can encrypt any data to send to me.
So if I have a keypair, and I publish my public key; and you have a keypair and you publish your public key, we can then each encrypt messages to send to each other. As long as we keep our private keys safe, nobody knows what we're saying to each other. Although they can still see me sending messages to you, and they can see you sending messages to me, nobody else can read them.
But immediately a problem springs to mind: if someone publishes a public key and says "This key belongs to SuperDuperStore; please encrypt your credit card and send it to them", how do you know if that public key really belongs to SuperDuperStore, and not EvilHackers?
The primary way that's been solved is through the use of "digital certificates", and this is where it gets more complicated. A certificate uses another form of asymmetric cryptography known as a digital signature. The digital signature uses a keypair just like our encryption, but instead the private key is used to create a "signature" of your public key. The signature is a big number that only the signer's private key can create, but anyone with the signer's public key can verify it. The signature and the public key are put together in a specially formatted data structure called a certificate. So if you know you have a copy of the signer's certificate (containing SuperDuperStore's public key), you can use the signer's public key to verify that only the signer could have created the signature.
We call these signers of other people's keys "Trusted Certificate Authorities", or CAs for short. Their job is to prove to everyone that a public key really belongs to SuperDuperStore by signing those certificates. They do this by verifying that each request to sign a public key really came from SuperDuperStore, or Sangstar, or John. Once they verify the request, they digitally sign your certificate request and send you back the signed certificate.
But now it's turned into a chicken-and-egg problem - how do you trust that you have the CA's real public key? First, we have the CA sign their own public key, creating what is called a self-signed certificate. It's a secure document, but how do we know it's not just self-signed by EvilHackers? By only trusting delivery of those self-signed certificates to trustworthy entities. That copy of Windows, or MacOS, or Firefox, or Chrome, or Android, or iOS, or Linux that you're using right now? It was shipped to you with over a hundred trusted self-signed certificates pre-installed. Any self-signed certificate that's not already on the list wasn't signed by a trusted CA, and your browser or computer will reject it, warning you that it is not a legitimate certificate.
Finally, you asked if these keys are persistent, or if they're constantly changed. The answer is on the signed certificates containing the public keys. Each certificate has a "Not After" (expiration date) field, and once a certificate is too old, it is no longer trusted by anyone else. Before that happens you'll want to get a new certificate and publish it; it turns out this is usually a good time to generate a new keypair, too.